The company may perform well.

Its local share price may increase.

But if the company’s currency falls far enough against the investor’s home currency, the final return can shrink—or disappear entirely.

The reverse can also happen.

A mediocre local return can become attractive because the foreign currency strengthened.

This is why a global backtest cannot simply collect stock prices from several countries and place them into one portfolio.

Every return must eventually be expressed in a common currency.

Otherwise, the portfolio may report profits that no investor actually earned.

A stock has more than one return

Suppose a Canadian investor buys a German stock.

The stock rises by 12% in euros.

That is the local-market return.

But the investor began with Canadian dollars and eventually wants the investment measured in Canadian dollars.

During the holding period, the euro may strengthen or weaken against the Canadian dollar.

The investor’s result therefore depends on two movements:

1. The stock’s return in euros

2. The euro’s movement against the Canadian dollar

The stock and the currency work together.

A global investment is not merely ownership of a foreign business.

It also creates currency exposure.

A simple example

Imagine a stock begins at €100 and ends at €110.

The local return is 10%.

At the beginning, suppose one euro is worth $1.50 Canadian.

The investment begins with a Canadian-dollar value of:

€100 × $1.50 = $150

By the end, suppose the euro has weakened to $1.30 Canadian.

The final Canadian-dollar value becomes:

€110 × $1.30 = $143

The company’s stock rose by 10% in its home market.

The Canadian investor lost about 4.7%.

Nothing is wrong with the company’s local price history.

The missing piece is the currency conversion.

Currency can also improve the result

Now imagine the same stock rises from €100 to €110, but the euro strengthens from $1.50 Canadian to $1.65.

The final value becomes:

€110 × $1.65 = $181.50

The investor’s Canadian-dollar return is 21%.

The stock contributed 10%.

Currency movement added the rest.

This does not mean the investor intentionally made a currency forecast.

The exposure appeared automatically when the foreign asset was purchased.

Local returns are still useful

A stock’s native-currency return tells us something important.

It reflects how the company was valued in its local market.

It allows comparisons with domestic competitors.

It helps separate company performance from currency movement.

But local returns do not represent the complete experience of a foreign investor.

A proper system may therefore preserve both:

• The native-currency stock return

• The portfolio-currency return

The first helps analyze the business and its local market.

The second tells us what the investor actually earned.

One portfolio needs one measuring unit

A global portfolio may contain companies trading in:

• U.S. dollars

• Canadian dollars

• British pounds

• Australian dollars

• Euros

• Other currencies

These values cannot be added directly.

A $1,000 position, a £1,000 position, and a €1,000 position do not represent the same amount of capital.

Before measuring portfolio weights or returns, the values must be converted into a shared unit.

This is similar to measuring a building.

One worker reports centimetres.

Another reports inches.

Another reports metres.

The measurements may all be correct individually.

Adding them without conversion produces nonsense.

A portfolio requires a common financial language.

Trading currency and reporting currency may differ

Currency problems become more complicated because a company can involve several currencies at once.

A business may:

• Trade in one currency

• Report financial statements in another

• Earn revenue across several currencies

• Be evaluated by an investor using a third currency

For example, a company may trade in London while earning most of its revenue in U.S. dollars.

Another may trade in Canada while reporting certain operating results in U.S. dollars.

The ticker’s exchange does not always tell us the complete economic exposure.

The system must distinguish among:

• Trading currency

• Financial-statement currency

• Operational currency exposure

• Portfolio reporting currency

These are related but different concepts.

Financial ratios also require currency consistency

Currency conversion is not only a return problem.

It affects valuation.

Suppose a company’s market capitalization is calculated in Canadian dollars while its free cash flow remains in U.S. dollars.

Dividing one by the other produces a number.

That number has no valid economic interpretation.

Before calculating ratios such as price to free cash flow, the numerator and denominator must use compatible units.

This applies to:

• Market value and earnings

• Enterprise value and operating profit

• Price and book value

• Debt and cash flow

• Portfolio value and position size

A clean ratio requires more than the correct formula.

Its ingredients must speak the same currency.

This is one way apparently attractive opportunities can be manufactured by a broken pipeline:

A currency mismatch can make a normal company look extraordinarily cheap or absurdly expensive.

Pounds and pence are not the same unit

Some markets create an additional complication.

A stock listed in London may be quoted in pence rather than pounds.

One pound contains one hundred pence.

A displayed stock price of 250 may mean 250 pence, or £2.50.

If a database interprets the number as £250, the stock becomes one hundred times more expensive than it really is.

If the opposite error occurs, the company may appear one hundred times cheaper.

This is not an exchange-rate problem in the usual sense.

It is a unit problem inside the currency.

A robust database must track both:

• Currency

• Quotation unit

“GBP” and “GBX” cannot be treated as interchangeable without conversion.

Currency errors often create extreme results

A currency mismatch can produce valuation ratios that look almost impossible.

That is exactly why the error can attract attention.

A company may appear to have:

• A price-to-earnings ratio below 1

• A free-cash-flow yield above 100%

• A market capitalization smaller than one quarter’s profit

• A sudden historical collapse or explosion in value

These results can look like extraordinary opportunities.

They should first be treated as validation failures.

Extreme numbers are often evidence that the system should inspect:

• Currency

• Units

• Share count

• Corporate actions

• Reporting period

• Company identity

The strongest apparent bargain may be the record most urgently requiring repair.

The exchange rate must match the date

Using the correct currency pair is not enough.

The system also needs the correct exchange rate for the relevant date.

Suppose a historical portfolio buys a German stock on March 31, 2018.

Using today’s euro exchange rate to convert that purchase would rewrite the historical transaction.

The correct rate should correspond to the investment date—or to a documented nearby date when markets were open.

The same principle applies when:

• Calculating entry value

• Calculating exit value

• Measuring daily portfolio value

• Converting financial statements

• Calculating position sizes

• Rebalancing the portfolio

A point-in-time backtest needs point-in-time currency information.

Missing FX dates create hidden assumptions

Stock markets and currency markets do not always share identical calendars.

A stock exchange may be closed while the currency still trades.

A currency data source may omit a holiday.

A financial statement may use a weekend period-end date.

The system may therefore need a rule for missing exchange-rate dates.

Possible approaches include:

• Use the most recent prior available rate

• Use the next available rate

• Use a monthly average

• Reject the calculation until an exact rate exists

Each approach has consequences.

The important thing is not pretending that no decision was made.

The policy should be documented and applied consistently.

A silent fill can create point-in-time errors that are difficult to detect later.

Monthly averages and daily rates answer different questions

A company’s annual financial statements may reasonably be translated using an average exchange rate for flows such as revenue or expenses.

A balance-sheet item may be translated using the rate on the reporting date.

A stock transaction should usually use the rate available on the transaction date.

These are different conversion problems.

Revenue accumulated throughout a year.

Cash on the balance sheet existed at one point in time.

A stock was purchased on a specific date.

Using one universal exchange rate for every purpose may simplify the database while distorting the economics.

The conversion rule should match the type of value being converted.

Currency conversion must not create look-ahead bias

Suppose an exchange-rate series is revised later.

Or a monthly average is calculated using the entire month, including days after the simulated investment decision.

The backtest may quietly receive future currency information.

This can matter when the strategy uses converted financial metrics for ranking.

If a company’s valuation is calculated using an exchange rate unavailable on the decision date, the historical screen is no longer honest.

The same point-in-time discipline applied to financial filings must also apply to FX data.

Otherwise, the backtest may know more than the investor could have known.

This is one reason impressive historical results require careful skepticism:

A correct formula applied with future currency information still produces an invalid test.

Currency affects position sizing

Suppose the portfolio intends to allocate $10,000 Canadian to each of ten holdings.

One stock trades in U.S. dollars.

Another trades in euros.

Another trades in Australian dollars.

The system must convert the intended Canadian-dollar allocation into each trading currency before determining how many shares to purchase.

If the exchange rate is wrong, the positions will not be equal.

One may receive $8,000 of exposure.

Another may receive $12,000.

The portfolio appears equal-weighted in the model but is unequal in reality.

Accurate currency conversion is therefore part of allocation, not merely performance reporting.

Rebalancing creates repeated FX decisions

A long-term global portfolio does not convert currency only once.

Each rebalance may involve:

• Selling foreign shares

• Converting the proceeds

• Purchasing securities in another currency

• Measuring new target weights

• Recording transaction costs

If a strategy rotates among countries, its currency exposure also changes.

A backtest that ignores these conversions may understate costs and mismeasure allocation.

The effect may be small for a low-turnover strategy.

It can become substantial when rebalancing is frequent.

Currency conversion has costs

The market exchange rate shown in a database may not be the exact rate available to a retail investor.

Real conversions can include:

• Bid-ask spreads

• Broker markups

• Conversion commissions

• Settlement differences

• Minimum fees

These frictions reduce returns.

A backtest does not need to model every brokerage detail perfectly to be useful.

But it should not assume unlimited free conversion when the portfolio regularly trades across currencies.

The more frequently the strategy converts capital, the more important these costs become.

Holding foreign currency can sometimes reduce conversion frequency

An investor may maintain cash balances in several currencies.

Proceeds from selling a U.S. stock can remain in U.S. dollars and later fund another U.S. purchase.

This can reduce repeated conversion costs.

But it creates another portfolio position:

Foreign cash.

That cash changes value relative to the investor’s home currency.

The system must decide whether currency balances are:

• Converted immediately

• Held until needed

• Treated as portfolio assets

• Included in performance

There is no universal correct answer.

The rule should reflect how the strategy would actually operate.

Hedged and unhedged returns are different strategies

Some investors accept currency movement.

Others hedge it using financial instruments designed to reduce exchange-rate exposure.

These approaches should not be mixed.

An unhedged foreign-stock return includes currency movement.

A hedged return attempts to isolate more of the local asset return, though hedging has costs and may be imperfect.

The choice depends on:

• Investment horizon

• Currency volatility

• Hedging costs

• Portfolio objectives

• Available instruments

A backtest should clearly state whether foreign positions are hedged.

Otherwise, two strategies may appear comparable while carrying different sources of risk.

Currency exposure can create diversification

Currency movement is not always an unwanted problem.

It can provide diversification.

A Canadian investor whose portfolio is entirely denominated in Canadian dollars depends heavily on one currency.

Owning assets connected to U.S. dollars, euros, or other currencies may reduce that concentration.

During some periods, foreign currencies may strengthen when the investor’s home market weakens.

This can support portfolio value.

During other periods, it can work against the investor.

Currency exposure is neither automatically good nor bad.

It is a source of risk and return that should be visible.

The company’s economic exposure may not match its listing

A Canadian-listed company may earn most of its revenue in the United States.

A British-listed miner may sell commodities priced globally in U.S. dollars.

A German manufacturer may export heavily to Asia.

The trading currency tells us how the shares are quoted.

It does not tell us where the company earns its money.

This distinction matters because currency can affect the business before it affects the investor.

A weaker home currency may increase the translated value of foreign revenue.

It may also increase the cost of imported materials.

The company may use hedges of its own.

A complete analysis separates:

• The investor’s currency exposure

• The company’s operating currency exposure

The two can interact in complicated ways.

Converted statements can hide native economics

For comparison, the database may convert every company’s financial statements into one currency.

That makes cross-country ratios easier to calculate.

But the native values should remain preserved.

Suppose a company’s revenue grows by 5% in its home currency.

After conversion, it appears to fall because the currency weakened.

The business did not necessarily shrink locally.

The investor’s translated view changed.

Both facts matter.

Native values help measure operating progress.

Converted values help compare capital across the global portfolio.

Deleting the native record would lose important context.

This is another reason raw financial history should remain durable:

Conversion policies can change.

The original evidence should remain available for rebuilding.

One conversion direction must be chosen consistently

Currency pairs can be quoted in opposite directions.

One source may report:

USD per EUR

Another may report:

EUR per USD

These values are reciprocals.

Confusing them can completely reverse a conversion.

If one euro equals 1.10 U.S. dollars, then one U.S. dollar equals about 0.91 euros.

Multiplying when the system should divide can create large errors.

The database should define every FX pair clearly.

Names such as EUR_USD can still be ambiguous unless the convention is documented.

A robust pipeline should know:

• Base currency

• Quote currency

• Conversion direction

• Formula applied

Synthetic currency pairs require care

A data provider may not supply every currency pair needed by the portfolio.

The system may need to calculate one through a common currency.

For example:

• Convert Australian dollars to U.S. dollars

• Convert U.S. dollars to Canadian dollars

• Combine the two to obtain Australian dollars to Canadian dollars

This is a synthetic cross-rate.

It can be perfectly valid.

But both component rates must correspond to compatible dates and conventions.

A mistake in either leg affects the final result.

The derived pair should retain provenance showing how it was constructed.

Stable conversion policy matters more than perfect precision

Historical FX data from different sources may vary slightly.

One may use daily closing rates.

Another may use central-bank reference rates.

Another may use market averages.

The exact values may not match perfectly.

For many long-term backtests, consistency is more important than chasing false precision.

The system should choose a reasonable source and apply it uniformly.

Switching providers whenever one produces a more attractive result would contaminate the research.

A conversion policy should be based on accuracy and availability—not on whether it improves performance.

The database and strategy have different FX responsibilities

The database should preserve:

• Native values

• Currency identifiers

• FX rates

• Dates

• Units

• Source information

• Conversion results

• Missing-rate states

The strategy decides:

• Portfolio reporting currency

• Whether positions are hedged

• Whether foreign cash is held

• Which conversion costs are applied

• How currency affects allocation

This separation follows the broader distinction between financial memory and investment policy:

The database provides the conversion evidence.

The strategy determines how foreign exposure is handled.

FX errors can contaminate every layer

A single currency problem can spread widely.

It may affect:

• Market capitalization

• Valuation ratios

• Screening eligibility

• Company rankings

• Position sizes

• Portfolio weights

• Historical returns

• Risk statistics

• Outcome labels

• Machine-learning targets

By the time the final backtest looks wrong, the original FX mistake may be several layers away.

This is why currency validation should happen early in the pipeline.

Bad conversion should not be allowed to become a sophisticated investment score.

Useful validation checks

A global system can test for suspicious results.

For example:

• Did the exchange rate change by an impossible amount?

• Is a British stock being treated as pounds when it is quoted in pence?

• Are the statement and market-value currencies aligned?

• Is a required date missing?

• Did converted market capitalization change dramatically without a price or share-count change?

• Are reciprocal currency pairs consistent?

• Does another reliable source show a similar rate?

These checks do not guarantee perfection.

They catch many errors before those errors become investment decisions.

The home currency must be explicit

“Global return” is incomplete without naming the investor’s measuring currency.

A Canadian investor, American investor, and European investor can earn different home-currency returns from the same stock over the same period.

The underlying company and local share-price return are identical.

The conversion path differs.

A backtest should therefore state its portfolio currency clearly.

For my system, I may standardize research values into a common reference currency while also preserving native information.

The important part is that the choice is explicit and reproducible.

Comparing countries requires converted outcomes

Suppose the system wants to compare six-month returns among companies from Canada, Australia, Germany, Britain, and the United States.

Using only native returns can be useful for studying local stock selection.

But if those companies are competing for positions inside one real portfolio, converted returns matter.

A 15% Australian-dollar gain and a 12% euro gain cannot be compared completely without considering how those currencies moved relative to the portfolio currency.

Otherwise, the system may learn that one country produced stronger returns when much of the difference came from FX.

That may still be useful information.

It should not be mislabeled as company-selection skill.

Currency can distort outcome labels

Future models may be trained using labels such as:

• Six-month return

• Six-month market-relative alpha

• Maximum drawdown

• Disaster outcome

• Twelve-month continuation

If those outcomes mix native and converted currencies inconsistently, the model learns from incompatible targets.

One country’s companies may appear systematically better or worse because of the currency treatment.

The problem is especially dangerous because the labels look like ordinary numbers.

The model may find strong patterns.

It may be learning a pipeline inconsistency.

The output currency of every outcome should be defined clearly.

Benchmark returns require the same treatment

Market-relative performance compares a stock with a benchmark.

The stock and benchmark must be measured consistently.

Suppose a German stock’s return is converted into Canadian dollars, while the German benchmark remains in euros.

The resulting alpha mixes company performance with currency movement.

The comparison is invalid.

Possible valid approaches include:

• Compare stock and benchmark in their shared native currency

• Convert both into the portfolio currency

• Separate local alpha from FX contribution

Each answers a different question.

The system should decide which question it wants to ask.

Decomposing the return improves understanding

A foreign investment’s return can be separated conceptually into:

• Local stock return

• Currency return

• Interaction between the two

This helps explain performance.

Suppose a position gained 18% in Canadian dollars.

Perhaps the stock rose 10% locally and currency contributed most of the rest.

Another position may have fallen 5% even though the company rose locally, because its currency weakened sharply.

Without decomposition, the investor may credit or blame the company for movement caused elsewhere.

A transparent system should explain both sources.

Currency movements can dominate short periods

Over long periods, business performance may become the primary driver of value.

Over shorter periods, currency movement can dominate.

A company may report no major change, yet its converted stock value moves significantly because exchange rates changed.

This matters when the strategy uses short holding periods or frequent rebalancing.

A six-month strategy may experience much more FX noise than a twenty-year investor expects.

The system should not assume currency becomes irrelevant simply because the selected companies are fundamentally strong.

Global diversification is still valuable

These complications do not mean investors should avoid foreign markets.

Global investing can provide access to:

• Different industries

• Different economic cycles

• Different valuations

• Different currencies

• Companies unavailable domestically

• Reduced dependence on one country

The lesson is not that currency risk makes global investing impossible.

It is that the benefit must be measured honestly.

Diversification cannot be evaluated accurately when each country’s returns use a different ruler.

The goal is an investable backtest

A useful backtest should describe something an investor could realistically have done.

For a global portfolio, that means knowing:

• What each stock cost in its trading currency

• What the exchange rate was

• How much home-currency capital was allocated

• What conversion costs applied

• What the position was worth later

• Whether proceeds remained foreign or were converted

• What information was available on each date

Ignoring currency creates a simpler simulation.

It may also create a simulation no investor could reproduce.

The final principle

Currency conversion does not create value.

It reveals whose value is being measured.

A company operates in one economic world.

Its stock trades in a market currency.

The investor experiences the result in a portfolio currency.

Those layers cannot be collapsed carelessly.

A global backtest should preserve native prices, native financial statements, trading currencies, historical FX rates, and the exact conversion policies used.

It should measure every portfolio position in a common unit without erasing the local evidence underneath it.

Otherwise, stock-selection skill, currency movement, and data errors become mixed together.

A foreign stock can rise while the investor loses money.

It can fall locally while currency softens the damage.

A company can appear cheap merely because its financial statements and market value use different units.

The arithmetic may look correct while the investment never truly existed.

Global investing expands the opportunity set.

Currency conversion makes that opportunity set measurable.

Without it, the portfolio is not global.

It is a collection of incompatible numbers.

Subscribe now

Share

Share Fungal Intelligence for Stocks

Leave a comment

An investment strategy can produce a clear buy signal while depending on only a small part of that database.

These two systems work together.

They are not the same thing.

The database preserves evidence.

The strategy applies beliefs, rules, and objectives to that evidence.

Confusing those responsibilities can create a system that appears intelligent but is difficult to verify, modify, or trust.

That is why I treat my financial database and my investment strategy as separate parts of the project.

A database describes

A financial database attempts to describe the market.

It may contain:

• Company identities

• Financial statements

• Filing dates

• Reporting periods

• Share prices

• Trading currencies

• Exchange rates

• Share counts

• Corporate actions

• Industry classifications

• Missing-data records

• Provider metadata

None of these facts tells the investor what to do by itself.

A company reported $500 million in revenue.

Its share count increased by 4%.

Its debt declined.

Its stock traded at a particular price.

These are observations.

They become investment information only after a strategy places them into context.

A strategy decides

An investment strategy asks questions that the database cannot answer alone.

For example:

• Is the company profitable enough?

• Is its debt manageable?

• Is the valuation attractive?

• Is growth healthy?

• Is dilution excessive?

• Does it fit the portfolio?

• Should it be rejected?

• How much capital should it receive?

These questions depend on objectives.

A conservative value strategy and an aggressive growth strategy can examine the same company and reach opposite conclusions.

Neither conclusion is stored naturally inside the company’s financial statements.

The difference comes from the rules being applied.

Facts do not contain their own verdict

Suppose a company has debt-to-equity of 1.8.

Is that high?

The database cannot answer without additional context.

For a stable infrastructure business, the debt may be manageable.

For a fragile cyclical company, it may be dangerous.

For a bank, the ratio may not even be the correct way to think about financial structure.

The number is real.

The verdict depends on the business model and the investment strategy.

That is why facts and conclusions should remain distinguishable.

The same database can support opposing strategies

Imagine two investors studying the same market.

The first searches for high-quality companies with stable cash flow and moderate valuations.

The second searches for distressed companies with a chance of recovery.

The quality investor may reject a business because:

• Earnings are negative

• Debt is rising

• Revenue is falling

• Cash flow is unstable

The distressed investor may examine that exact company because those weaknesses caused the price to collapse.

Both strategies can use the same database.

They simply interpret the evidence differently.

A database should not quietly delete the company because one strategy does not want it.

The evidence may still matter to another strategy—or to evaluating whether the first strategy’s rejection rule was useful.

A screener belongs to the strategy layer

A stock screener often looks like a database tool because it searches financial fields.

But a screener is already expressing an investment opinion.

The moment it says:

• Market capitalization must exceed $300 million

• Free cash flow must be positive

• Debt-to-equity must remain below 2.5

• Price-to-free-cash-flow must remain below 25

it has moved beyond recording facts.

It is applying a strategy.

The company does not become objectively unsuitable because it failed those rules.

It becomes unsuitable for that particular investment process.

This is why a screener’s role should be understood clearly:

The database stores the company.

The screener decides whether the company may proceed.

The database should not care which strategy wins

A reliable database should remain neutral between competing ideas.

Suppose Strategy A performs better when it emphasizes valuation.

Strategy B performs better when it emphasizes quality.

Strategy C performs better when it combines both.

The underlying historical evidence should remain unchanged across all three tests.

If each strategy uses a differently cleaned or differently filtered version of history, the comparison becomes unfair.

The database should create a common world.

The strategies should compete inside that world.

Strategy rules should remain replaceable

Investment theories change.

A ratio that appears powerful in one test may fail in another.

A threshold may turn out to be too strict.

A company classification may need improvement.

The portfolio may require stronger country limits.

These are normal research developments.

If the rules are embedded directly into the data, changing the strategy may require rewriting the database.

That risks changing the historical world whenever the investment theory changes.

A better design keeps the evidence stable and makes the strategy replaceable.

This is the broader architecture behind:

The database should outlive individual strategies.

A database is broader than a strategy

A strategy uses only the fields needed for its current decisions.

The database should usually preserve more.

A general operating strategy may currently care about:

• Revenue

• Net income

• Free cash flow

• Debt

• Book value

• Share count

• Valuation

But future research may need:

• Inventory

• Receivables

• Lease obligations

• Interest expense

• Research spending

• Segment results

• Acquisition history

• Customer concentration

If the system stores only what one strategy currently requires, future questions become impossible to test.

The database should preserve possibilities.

The strategy should narrow them into decisions.

A strategy is more than a formula

It is easy to imagine an investment strategy as a scoring equation.

Perhaps value receives 25%, quality receives 25%, growth receives 20%, and safety receives 30%.

But a complete strategy contains much more.

It includes:

• Which companies are eligible

• Which business models are excluded

• Which data is required

• Which values trigger rejection

• How companies are ranked

• How many positions are held

• How often the portfolio rebalances

• How positions are sized

• When a stock is sold

• How trading costs are handled

• What happens when no candidate qualifies

The database cannot make these choices automatically.

They reflect the investor’s goals and tolerance for uncertainty.

The database can be correct while the strategy is wrong

Suppose the financial data is accurate.

Prices, currencies, filing dates, and share counts have all been handled correctly.

The strategy still performs poorly.

Perhaps it:

• Overvalues growth

• Ignores deterioration

• Uses weak valuation measures

• Concentrates in one industry

• Trades too frequently

• Overfits historical relationships

This is a strategy failure, not a database failure.

The distinction matters because the repair is different.

The data does not need to be recollected.

The investment rules need to be reconsidered.

The strategy can be reasonable while the data is wrong

The opposite can also occur.

The strategy may have sensible rules, but it receives:

• A stale stock price

• The wrong company’s financial statement

• An outdated share count

• A currency mismatch

• A duplicated filing

• A future filing inside a historical test

The strategy produces a bad decision because the evidence was corrupted.

Changing the investment rules will not repair the problem.

The pipeline must be fixed.

This is how poor inputs can manufacture attractive-looking stocks:

A system must know whether it misunderstood reality or received the wrong reality.

The distinction makes failures useful

When an investment system fails, I want to know where it failed.

Was the problem:

1. Source data?
   The provider returned an incorrect or incomplete record.

2. Transformation?
   Currency, units, dates, or corporate actions were handled incorrectly.

3. Classification?
   The company was judged using the wrong business model.

4. Screening?
   The mouth admitted a company that should have been rejected.

5. Scoring?
   The strategy emphasized the wrong financial characteristics.

6. Allocation?
   Reasonable companies were combined into a fragile portfolio.

7. Uncertainty?
   The process was defensible, but the future still went badly.

Each failure teaches a different lesson.

Mixing the database and strategy together makes these lessons harder to recover.

A database should preserve rejected companies

When a strategy rejects a company, the company should remain in the database.

Otherwise, the research history becomes biased toward the strategy’s preferences.

Rejected companies are valuable because they allow the system to measure:

• How many later recovered

• How many failed

• Whether thresholds were too strict

• Whether missing data caused excessive rejection

• Whether the strategy avoided major losses

• Whether certain business types were treated unfairly

A database should preserve the full population.

The strategy creates a temporary eligible population from it.

The database should also preserve the strategy’s decisions

Keeping the layers separate does not mean investment decisions should disappear.

The system should record:

• Which strategy version ran

• Which companies were eligible

• Which companies were rejected

• Why each rejection occurred

• Which scores were produced

• Which portfolio was constructed

• Which data snapshot supported the decision

This creates an audit trail.

The decision belongs to the strategy layer, but it should be permanently associated with the evidence that produced it.

Raw evidence allows the strategy to be rebuilt

Suppose I later discover that my definition of free cash flow was too simplistic.

If raw cash-flow records remain available, I can create a better definition and rerun the strategy.

Suppose a country requires a different filing-availability policy.

The historical snapshots can be rebuilt.

Suppose an entire business category needs specialized metrics.

The companies can be reclassified and reprocessed.

This is possible because the evidence was preserved before the strategy compressed it into scores.

That is why raw history should survive every current model:

Strategies are experiments.

The raw warehouse is the laboratory record.

A database does not create an edge by itself

A large financial database may be valuable infrastructure.

But possessing more data does not automatically produce better investment decisions.

The investor still needs to decide:

• Which information matters

• Which relationships are durable

• Which companies are comparable

• Which risks deserve rejection

• Which valuations provide enough margin of safety

A database can make research possible.

It cannot guarantee that the research question is intelligent.

More information can produce more sophisticated mistakes when the strategy lacks discipline.

A strategy does not create truth

A strategy can express a strong opinion.

It can rank every company from best to worst.

That confidence does not make the conclusion true.

A precise score may rest on:

• Uncertain estimates

• Arbitrary weights

• Weak historical relationships

• Incomplete data

• An overfit backtest

The strategy should therefore remain accountable to the evidence.

It should be possible to trace every conclusion backward.

The more decisive the output, the more important that chain becomes.

Machine learning still belongs to the strategy layer

A future machine-learning model may identify relationships too complicated for fixed rules.

It might estimate future returns, risk, or the probability of deterioration.

But the model is still an interpretation system.

It learns from selected features and selected outcomes.

Its predictions depend on choices involving:

• Training periods

• Feature definitions

• Labels

• Missing-data handling

• Model architecture

• Validation rules

The model does not replace the database.

It depends on it.

Powerful models increase the need for reliable, traceable evidence because mistakes become harder to see inside complex predictions.

The portfolio is not stored in the company data

A company can look attractive individually and still be a poor portfolio addition.

The database may show that several oil producers are financially strong and inexpensive.

The selection strategy may rank all of them highly.

The portfolio layer must recognize that owning several of them creates one large commodity exposure.

This is another example of a decision that exists outside the raw company facts.

The database describes each tree.

The portfolio strategy decides how the forest should be assembled.

Strategy performance should not rewrite the data

Suppose a strategy performs badly during a certain period.

There may be a temptation to:

• Remove unusual companies

• Replace inconvenient missing values

• Adjust classifications

• Change the historical universe

• Prefer a different provider because it produces better results

Some corrections may be legitimate.

But data changes should be made because they improve accuracy, not because they improve strategy performance.

The database should not be optimized to make the strategy look intelligent.

The strategy should be tested against the most honest database available.

One supports many; the other chooses one path

The database should be capable of supporting many strategies.

A value strategy may use it one way.

A quality strategy may use it another.

A bank-specific model may select different nutrients from a miner-specific model.

The strategy chooses one path through the evidence.

That path may succeed or fail.

The database remains available for the next question.

A useful architectural sequence

The project can be understood as a series of distinct layers:

1. Raw warehouse
   Preserve filings, provider responses, prices, currencies, identities, and metadata.

2. Cleaning and normalization
   Resolve units, dates, corporate actions, mappings, and obvious contradictions.

3. Point-in-time snapshots
   Reconstruct what information was available on each historical decision date.

4. Business classification
   Determine which financial rules belong to each company.

5. Screening
   Reject candidates that fail non-negotiable requirements.

6. Feature compilation and scoring
   Calculate relevant nutrients and rank the survivors.

7. Portfolio allocation
   Combine companies while controlling position size and shared risk.

8. Outcome tracking
   Record what happened after the decision.

9. Validation
   Test whether the strategy survives unseen conditions.

The first three layers primarily construct the historical world.

The later layers decide how to act inside it.

The distinction creates trust

When data and strategy are separated, the system can answer two different questions.

What did the system know?

This can be traced through:

• Source records

• Filing dates

• Prices

• Currencies

• Missing values

• Transformations

Why did the system act?

This can be traced through:

• Strategy version

• Screening rules

• Scores

• Thresholds

• Portfolio constraints

• Position sizes

Trust requires both answers.

A decision without evidence is unsupported.

Evidence without a decision process cannot explain the portfolio.

The database is memory; the strategy is policy

A useful way to understand the distinction is:

The database is memory.

It preserves what entered the system.

The strategy is policy.

It determines how the system responds.

Memory should be broad, durable, and honest.

Policy should be explicit, testable, and replaceable.

A system with policy but no reliable memory repeats mistakes.

A system with memory but no policy collects information without acting.

Both are necessary.

Neither should impersonate the other.

The final difference

A database asks:

What happened, when did it happen, and what evidence do we have?

An investment strategy asks:

Given that evidence, what should we reject, select, own, and risk?

The database attempts to reconstruct reality.

The strategy expresses a disciplined opinion about that reality.

The database can be accurate while the strategy fails.

The strategy can be sensible while the data pipeline fails.

Keeping them separate allows the project to discover which one needs repair.

The database remembers every company, including the failures and rejected candidates.

The strategy chooses which companies matter for one particular objective.

The database should survive changes in investment theory.

The strategy should earn trust through testing.

One preserves the world.

The other decides how to move through it.

That is the difference between a database and an investment strategy.

Subscribe now

Share

Share Fungal Intelligence for Stocks

Leave a comment

It has consistent names, standardized currencies, resolved duplicates, aligned periods, and calculated investment metrics.

That makes it tempting to keep only the cleaned result.

Once revenue growth, free cash flow, debt ratios, and valuation scores have been calculated, why preserve the awkward source records underneath them?

Because the cleaned result contains assumptions.

Those assumptions may later prove incomplete, inconsistent, or wrong.

If the original evidence has been deleted, the system cannot return to the point before the mistake was made.

That is why I want to keep raw financial data permanently.

The raw database is not merely storage.

It is the project’s memory.

Clean data is an interpretation

A company might report operating cash flow of $120 million and capital expenditures of $35 million.

The system calculates free cash flow of $85 million.

That looks simple.

But even this basic calculation contains decisions:

• Which cash-flow period was selected?

• Was the capital-expenditure value already negative?

• Were both figures reported in the same currency?

• Was the statement annual, quarterly, or trailing?

• Was the filing later restated?

• Was the company mapped to the correct security?

• Was the figure reported directly or estimated?

The final number is useful.

It is not raw truth.

It is the result of a process applied to the evidence.

Keeping the source data allows that process to be examined and repeated.

The database should remember more than the strategy needs today

My current strategy may use a limited set of metrics.

It may care about:

• Free cash flow

• Net income

• Revenue growth

• Debt

• Book value

• Share dilution

• Valuation

• Deterioration

• Trading liquidity

That does not mean these are the only fields that will ever matter.

A future version of the system may need:

• Inventory

• Receivables

• Customer concentration

• Segment results

• Capitalized costs

• Lease obligations

• Pension assumptions

• Interest coverage

• Acquisition spending

• Research expenses

• Deferred revenue

If I collect only what the current strategy uses, the database becomes trapped inside the current theory.

When the theory changes, the evidence required to test the new idea may already be gone.

This is one reason I am building a database instead of relying only on a finished screener:

A screener answers a predefined question.

A raw database preserves the ability to ask new questions later.

Raw data is like source code

In programming, a compiled application is useful because it can run.

But the executable is not a substitute for the source code.

The source code explains how the program was built.

It can be inspected, repaired, modified, and compiled again.

Clean financial features are similar to the executable.

Raw filings, provider responses, prices, mappings, and metadata are the source.

If I keep only the finished features, the system may continue running, but I lose the ability to understand exactly how it was constructed.

The calculations may still work.

The knowledge behind them becomes fragile.

Strategies change

Investment research is not a one-time process.

A strategy may begin by focusing heavily on valuation.

Later, testing may show that cheap companies with deteriorating cash flow perform poorly.

The system adds a deterioration check.

Later still, it may discover that companies issuing large amounts of stock frequently destroy shareholder value.

The system adds dilution.

Each improvement requires historical evidence.

If the raw data survives, the new feature can be compiled across the entire history.

The updated strategy can then be tested fairly.

If only the old scores remain, the system cannot reconstruct what would have happened under the improved rules.

The strategy changes.

The historical world should remain available.

Metric definitions change too

Even when the general idea remains useful, its definition may improve.

Free cash flow is a good example.

One version may calculate:

Operating cash flow minus capital expenditures

Another may attempt to distinguish maintenance spending from expansion spending.

Another may exclude unusually large working-capital movements.

A company’s result can change depending on the definition.

The original cash-flow statement should remain untouched.

Each strategy version can calculate the feature it needs from the same underlying evidence.

This makes comparisons cleaner.

The database stores the source.

The strategy stores the definition.

Raw data protects the separation between facts and opinions

An investment score is an opinion produced from evidence.

A filing value is closer to the evidence itself.

The two should not be confused.

Suppose a system stores only:

Quality score: 72

That number tells me almost nothing by itself.

Why was the score 72?

Which fields were used?

Which values were missing?

Which strategy version created it?

Was the company compared with banks, miners, or general operating businesses?

A score can be rebuilt when the evidence and rules remain available.

The evidence cannot be recovered from the score.

This is why my architecture separates the database from the decision-making layers:

The raw warehouse preserves what entered the system.

The strategy decides what to do with it.

Providers can change their history

Financial-data providers sometimes correct errors.

They may update old statements.

They may change field names.

They may replace a missing value.

They may revise how a metric is calculated.

A query made today may not return the same record that was received a year ago.

If I preserve each source response, I can see what the system actually knew at the time.

That matters for both debugging and historical testing.

Without the original response, it may become impossible to determine whether a changed result came from:

• A new company filing

• A provider correction

• A revised mapping

• A new calculation rule

• A software bug

• A different source entirely

Raw preservation creates a stable reference point.

Restatements require more than one version of history

Companies sometimes restate earlier financial results.

A previously reported value may be corrected months or years later.

For current analysis, the restated number may be the best available estimate of reality.

For point-in-time backtesting, the original number may be more important.

An investor making a decision before the restatement did not know the corrected value.

A durable warehouse may therefore need to preserve both:

• The statement originally available

• The later corrected statement

These are two different forms of truth.

One answers:

What is now believed to have happened?

The other answers:

What could an investor have known then?

Deleting the original version destroys the second question.

Filing dates must survive alongside financial periods

A statement may describe the year ending December 31.

That does not mean the market received it on December 31.

It might have been published in February, March, or later.

The period-end date describes the business activity.

The filing date describes when the information entered the world.

Both matter.

If the cleaned database keeps only the period-end date, a historical strategy may gain access to results before they were published.

That creates look-ahead bias.

Preserving raw dates and source metadata helps keep the simulation honest.

The financial value alone is not enough.

The timing of knowledge is part of the evidence.

Raw prices matter too

A historical price series may eventually be adjusted for:

• Stock splits

• Dividends

• Currency conversion

• Exchange differences

• Missing trading days

• Corporate actions

The adjusted series is useful for return calculations.

The original trading prices should still be preserved.

Suppose a stock split was handled incorrectly.

If only the adjusted history remains, it may be difficult to determine what happened.

With the original values and the corporate-action record, the series can be rebuilt.

Raw prices also help answer execution questions.

What price was actually quoted?

How much volume traded?

Was the price stale?

Was the security genuinely available?

An adjusted return series is not a complete trading record.

Currency conversions should remain reversible

Global financial data creates several layers:

• The company’s reporting currency

• The stock’s trading currency

• The investor’s portfolio currency

• The exchange rate used on each date

A cleaned feature may show that a company generated $200 million in U.S.-dollar-equivalent cash flow.

That is convenient for comparison.

But the original value may have been reported in euros, pounds, Canadian dollars, or Australian dollars.

Keeping the native figure and the exchange-rate record allows the conversion to be checked.

It also allows the system to change its currency policy later.

A Canadian investor and a U.S. investor may care about different converted outcomes.

The original currency remains the common source.

Raw data helps expose fake opportunities

Bad data can make a company appear dramatically mispriced.

A stale share count can understate market capitalization.

A pence-to-pound error can distort valuation by a factor of one hundred.

A duplicated filing can double earnings.

A negative capital-expenditure sign can inflate free cash flow.

Once the error has been transformed into a clean ratio, the fake opportunity may look completely legitimate.

The raw record provides the evidence needed to trace the mistake.

This matters because extreme investment results should not be trusted automatically:

The most exciting output may be the strongest reason to inspect the inputs.

A correction should not erase the mistake

Suppose the system incorrectly mapped one company’s financial statements to another company’s stock price.

The error is found and fixed.

It may seem reasonable to overwrite the bad record and continue.

But keeping an audit trail is valuable.

The system should know:

• What was wrong

• When it was discovered

• Which records were affected

• Which features were compiled from them

• Which historical selections changed

• Which reports or backtests used the bad result

• How the issue was repaired

The goal is not to preserve errors as valid data.

It is to preserve the history of how the system learned.

Without that history, the same mistake may return under a different form.

Failed strategies need the old evidence

Suppose a strategy performs poorly.

To understand why, I need the exact data it used.

If the underlying database has since been cleaned, corrected, or replaced, rerunning the strategy may produce a different result.

The failed version can no longer be reproduced.

That creates a temptation to explain the failure using today’s improved information.

But the strategy made its decisions using yesterday’s evidence.

Raw snapshots allow the failure to be studied honestly.

Was the strategy wrong?

Was the data wrong?

Did the market change?

Those are different lessons.

They require the original decision environment.

Reproducibility requires frozen inputs

A backtest should not change every time it is rerun unless the researcher intentionally changes something.

If the rules remain frozen but the results move, the data may have changed underneath them.

This makes scientific comparison difficult.

Preserving raw versions allows the system to create reproducible datasets.

A strategy can be tested against:

• Raw-data version 1

• Cleaning policy version 2

• Feature definition version 4

• Strategy rules version 3

This may sound technical, but the principle is simple.

The result should have an identifiable recipe.

Otherwise, performance can drift without a clear cause.

A permanent warehouse supports a lean working database

Keeping raw data forever does not mean every active process must load everything.

The system can use two layers.

The permanent warehouse

This stores:

• Original provider responses

• Raw filings

• Historical versions

• Source metadata

• Native currencies

• Raw prices

• Corporate-action records

• Missing or contradictory values

• Provenance

It is comprehensive and durable.

The lean research database

This contains only the features needed for the current strategies and backtests.

It may include:

• Current nutrients

• Point-in-time snapshots

• Selected prices

• Outcome labels

• Eligibility flags

• Strategy-ready features

The lean database can be rebuilt.

The warehouse should not need to be.

This is like keeping a freezer full of raw ingredients while preparing only the meals currently on the menu.

The menu can change.

The ingredients remain available.

Rebuilding is safer than endlessly patching

A derived database can accumulate old assumptions.

Fields may be calculated under different rules.

Some rows may use an earlier currency policy.

Others may use updated provider mappings.

Over time, the database becomes a mixture of historical logic.

If the raw warehouse remains intact, the derived database can be rebuilt from a clean specification.

Every record can pass through the same current transformation rules.

This is often safer than repairing millions of derived values one by one.

The raw store makes the system disposable in the right place.

Derived features are replaceable.

Source evidence is not.

Storage is cheaper than recollection

Raw financial data can consume substantial disk space.

Keeping old versions may appear inefficient.

But the alternative can be much more expensive.

Recollecting the data later may involve:

• New provider fees

• API limits

• Missing historical records

• Changed provider policies

• Delisted companies that are no longer available

• Different results from updated sources

• Weeks or months of engineering work

Disk space is often cheaper than rebuilding lost history.

The more difficult the dataset was to collect, clean, and document, the more valuable preservation becomes.

Delisted companies make preservation especially important

Active-company databases are easier to maintain because the securities still exist.

Failed and delisted companies are more fragile.

Their pages may disappear.

Provider coverage may weaken.

Ticker symbols may be reused.

Corporate information may become harder to obtain.

Yet these companies are essential for honest historical research.

They represent the failures that real investors could have selected.

If their raw records are not preserved, the market’s history gradually becomes cleaner than reality.

The losers disappear.

The survivors remain.

A permanent warehouse protects against this slow creation of survivorship bias.

Missing data may become available later

A filing that is incomplete today may be repaired later.

A provider may add history.

A ticker mapping may be resolved.

An exchange may clarify a corporate action.

Keeping the original missing state still matters.

The system may need to know that the value was unavailable at the historical decision date.

Later availability should not be backdated into the past.

This creates two useful records:

• What is known now

• What was known then

The absence itself is part of the historical environment:

A later correction should improve current understanding without rewriting what earlier investors could have seen.

Raw data makes estimation visible

Sometimes missing values may need to be estimated.

An estimated filing-availability date may be necessary for a country where exact publication dates are unavailable.

A financial feature may be reconstructed from related fields.

These estimates can be useful.

They should never become indistinguishable from reported facts.

The warehouse should preserve:

• The original missing value

• The estimation policy

• The estimated result

• The confidence level

• The date the estimate was produced

This allows the strategy to treat exact and estimated evidence differently.

It also allows the estimate to be replaced if better information appears.

Machine learning increases the need for raw preservation

A future machine-learning model may consume hundreds of derived features.

If the model behaves strangely, debugging the final prediction alone will not be enough.

The feature may be wrong because:

• The source data was incorrect

• A transformation changed

• A missing value was handled differently

• The company was classified incorrectly

• A filing was attached to the wrong date

• Currency conversion failed

Machine learning adds distance between the original evidence and the final decision.

That makes the underlying chain more important, not less.

A powerful model trained on flawed history becomes a more efficient way to repeat the flaw.

Raw preservation protects against accidental leakage

Outcome data must remain separate from decision inputs.

A future return, bankruptcy label, or later restatement should not enter the historical feature set before it existed.

When raw sources, transformed features, and outcomes are kept in distinct layers, leakage is easier to detect.

The system can ask:

• Was this field available on the decision date?

• Was it derived from a later filing?

• Did a cleaning rule use knowledge of the outcome?

• Was a company excluded because it later failed?

Without preserved source dates and versions, these questions become much harder to answer.

The system should never depend on memory alone

A researcher may remember why a field was transformed a certain way.

Months later, the reason becomes less clear.

Years later, it may be forgotten entirely.

Documentation helps.

Raw records provide stronger evidence.

They show exactly what entered the pipeline.

The system should not depend on me remembering:

• Which provider was used

• Why a value was rejected

• Which currency unit appeared

• Whether a filing was restated

• Which mapping was uncertain

• Why one company disappeared from the screen

A durable project needs memory outside the creator’s head.

Permanent does not mean untouchable

Keeping raw data forever does not mean treating every incoming value as correct.

Raw records can be marked as:

• Valid

• Invalid

• Superseded

• Duplicate

• Contradictory

• Estimated

• Unresolved

The key is that corrections should add context rather than erase history.

The system can say:

This was the original provider response. It was later found to be wrong for this reason. This corrected value replaced it in derived calculations.

That is more informative than silently changing the record.

Data deletion can create invisible strategy changes

Suppose a screening rule requires five years of revenue history.

A company originally failed because two years were missing.

Later, the missing history is deleted from the record entirely, leaving only the three visible years.

The strategy may no longer know that the company failed due to missing information.

It may interpret the shorter history as the complete history.

Small data deletions can therefore alter selection logic without any change to the formal rules.

Preserving raw states prevents absence from being rewritten as completeness.

A warehouse creates accountability

When every score can be traced back to its source, the system cannot easily hide behind complexity.

A company was selected because certain values, rules, and mappings produced the decision.

If the result was wrong, the chain can be inspected.

This makes failures more useful.

The project can distinguish between:

• Data failure

• Transformation failure

• Classification failure

• Strategy failure

• Portfolio-construction failure

• Ordinary uncertainty

Without the chain, every failure becomes a vague disappointment.

With it, failure can become information.

The warehouse should outlive individual strategies

Most investment strategies will eventually change, fail, or become obsolete.

A durable financial history can support many generations of research.

One strategy may focus on value.

Another may study business quality.

Another may examine deterioration.

A later system may use classification models, regression, optimization, or shadow portfolios.

The underlying market history remains useful across all of them.

The warehouse is therefore broader than the current project stage.

It is infrastructure for questions that have not yet been invented.

The raw data is an asset

Companies often treat data as an operational by-product.

For this project, the historical warehouse is one of the most valuable assets being built.

It contains:

• Time

• Provider access

• Cleaning work

• Mapping decisions

• Historical availability

• Failed-company records

• Country-specific knowledge

• Lessons from errors

• The ability to reproduce earlier experiments

Deleting the raw evidence would throw away much of that accumulated work.

The derived score may be visible.

The real value lies underneath it.

The final principle

I do not keep raw financial data because every field will definitely be useful.

I keep it because I do not yet know which fields, versions, dates, or mistakes will become important later.

Strategies change.

Definitions improve.

Providers revise history.

Bugs are discovered.

New questions appear.

A permanent warehouse allows the system to return to the evidence and begin again without pretending that the earlier assumptions were facts.

The cleaned database helps the strategy operate.

The raw database helps the project remain honest.

One is designed for speed.

The other is designed for memory.

Financial history is difficult to reconstruct after it has been discarded.

Storage can be reorganized.

Derived features can be rebuilt.

Strategies can be replaced.

The original evidence deserves to survive them all.

That is why I keep raw financial data forever.

Subscribe now

Share

Share Fungal Intelligence for Stocks

Leave a comment

Its earnings may be attached to the wrong share price.

Its financial statements may use one currency while its market value uses another.

A stock split may have adjusted the price but not the share count.

A missing value may have been replaced with zero.

An outdated filing may be compared with today’s price.

When this happens, the investment opportunity exists only inside the database.

The numbers look precise.

The conclusion is false.

That is why financial data quality is not merely a technical concern. It is part of investment risk.

A ratio is only as reliable as its ingredients

Financial ratios often feel objective because they produce clean numbers.

A company may have:

• A price-to-earnings ratio of 6

• A price-to-book ratio of 0.5

• A free-cash-flow yield of 18%

• Revenue growth of 24%

• Debt-to-equity of 0.4

These figures can immediately attract attention.

But every ratio is built from underlying inputs.

A price-to-earnings ratio depends on:

• The correct stock price

• The correct earnings period

• The correct share count

• Matching currencies

• The correct company identity

• Proper treatment of unusual items

If one ingredient is wrong, the finished ratio can become meaningless.

A sophisticated formula cannot rescue contaminated inputs.

The fake bargain

Suppose a company appears to produce $100 million in annual earnings.

Its market capitalization appears to be $500 million.

The system calculates a price-to-earnings ratio of 5.

That looks extremely cheap.

But imagine that the market capitalization was calculated using an old share count from before the company issued a large number of new shares.

The true market capitalization might be $900 million.

The company was never trading at five times earnings.

The bargain was created by stale data.

An investor could spend hours researching the company, building a thesis, and becoming emotionally attached to an opportunity that disappeared as soon as the inputs were corrected.

Wrong ticker mappings can combine two different companies

Ticker symbols are not permanent global identities.

The same symbol can exist on multiple exchanges.

A ticker can change after a merger.

A delisted company’s symbol may later be reused.

A provider may use one suffix while another uses something different.

If the system maps a company’s financial statements to the wrong security, it can combine:

• One company’s earnings

• Another company’s price

• A third company’s currency

• An outdated share count

The resulting valuation may look spectacular.

It is also fictional.

This is one reason a database should preserve company identities, exchange information, provider symbols, and mapping confidence—not merely a short ticker symbol.

Currency mistakes can create enormous distortions

Global investing introduces another source of false opportunity.

Suppose a company reports revenue and earnings in Australian dollars, but its market value is accidentally treated as U.S. dollars.

Or a stock trading in British pence is interpreted as though it were trading in pounds.

A share priced at 250 pence should represent £2.50.

If the system interprets it as £250, the company appears one hundred times more expensive than it really is.

The reverse mistake can create an apparently unbelievable bargain.

Currency problems can affect:

• Market capitalization

• Earnings

• Cash flow

• Debt

• Book value

• Historical returns

• Portfolio performance

A ratio is valid only when its numerator and denominator speak the same financial language.

Foreign exchange changes the investor’s actual return

Even when company-level ratios are calculated correctly, portfolio returns can still be distorted.

A German stock may rise in euros while the euro falls against the investor’s home currency.

The local business performed well.

The investor’s converted return may be weaker.

A backtest that mixes native-currency prices with dollar-denominated portfolio values may report returns that no investor could have earned.

The system should distinguish between:

• Native prices for local trading behaviour

• Converted prices for portfolio truth

• The exchange rate available on each date

• The currency in which the financial statements were reported

Without that separation, international diversification can become mathematically inconsistent.

Stock splits can manufacture growth or collapse

Stock splits should not change the economic value of a company.

If one share becomes ten shares, the price per share should fall proportionally.

But databases do not always adjust every field consistently.

Suppose historical prices are split-adjusted, but historical share counts are not.

The system may conclude that:

• Market capitalization collapsed

• Earnings per share changed dramatically

• Share dilution occurred

• Valuation ratios improved overnight

None of those conclusions may be real.

The company simply changed the number of pieces into which ownership was divided.

Corporate actions must be treated consistently across price, share count, and per-share calculations.

Dilution disappears when share-count history is weak

A company can grow while repeatedly issuing new shares.

Revenue rises.

Total earnings rise.

The business becomes larger.

But each existing shareholder may own a smaller percentage of the company.

If the database contains only the latest share count, the system may miss years of dilution.

A company that increased total earnings by 50% while doubling its share count did not improve earnings per share.

The business grew.

The shareholder’s claim on the business weakened.

Bad share-count data can transform dilution into apparent growth.

That can make an expensive financing habit look like successful expansion.

Missing values can become imaginary strength

A blank field should mean that the system does not currently know the value.

But some pipelines replace missing values with zero.

This is dangerous.

Missing debt becomes zero debt.

Missing dilution becomes zero dilution.

Missing capital expenditures can make free cash flow appear stronger.

Missing losses can disappear from a growth calculation.

The system may then reward a company for information it never received.

Unknown is not a favourable result.

It is an unresolved state.

The investment process should recognize that boundary:

A company should not pass a test merely because the system was unable to perform it.

Duplicate filings can double the company’s apparent performance

Financial providers may store annual and quarterly records together.

A company may report the same period more than once after restating its results.

Two providers may deliver overlapping versions of the same filing.

If duplicates are not detected, the system may add values that should never have been combined.

Revenue can appear to double.

Cash flow can be counted twice.

Growth rates can jump unexpectedly.

The database may still contain legitimate-looking rows.

The error appears only when the records are interpreted as a time series.

Deduplication therefore requires more than removing identical rows.

The system must understand reporting periods, filing dates, statement types, and restatements.

Annual, quarterly, and trailing figures can be mixed incorrectly

A company’s latest annual earnings should not be compared directly with another company’s latest quarter as though they covered the same amount of time.

Yet this can happen when a database stores figures without clearly preserving their period.

One company may show twelve months of revenue.

Another may show three months.

A third may show a provider-calculated trailing figure.

The ranking system compares them as though they were equivalent.

The shorter-period company may look unusually small, unusually cheap, or unusually fast-growing.

Every financial value needs a clear period:

• Fiscal year

• Fiscal quarter

• Trailing twelve months

• Year-to-date

• Point-in-time balance

Without period discipline, comparisons become arithmetic without meaning.

Filing dates and period-end dates are different

A company may report results for the year ending December 31.

Investors might not receive those results until February or March.

A backtest that makes the December figures available on December 31 gives the strategy information from the future.

The numbers are historically correct.

Their availability date is wrong.

This creates a fake opportunity because the simulated investor can buy before the market had access to the evidence supporting the purchase.

Point-in-time research must distinguish between:

• The period the results describe

• The date the filing became public

• The date the system could reasonably have processed it

• The date the strategy acted

Without that chain, a backtest can become unintentionally clairvoyant.

Restated history can give the strategy knowledge investors lacked

Companies sometimes revise earlier financial statements.

Errors are corrected.

Accounting policies change.

Later filings may present a cleaner version of the past.

A modern database might replace the original historical value with the corrected one.

That is useful for understanding the company today.

It can be misleading for simulating an earlier investor.

The earlier investor saw the original filing, not the later correction.

A point-in-time database may therefore need to preserve both:

• What is now believed to be correct

• What was actually known at the historical decision date

Otherwise, the strategy learns from corrections that had not yet happened.

A beautiful backtest can be built on information unavailable in real life:

A historical test is only meaningful when its information was historically available.

Provider-defined metrics may hide inconsistent formulas

A data provider may offer a ready-made free-cash-flow field.

That seems convenient.

But how was it calculated?

One provider may subtract capital expenditures from operating cash flow.

Another may include acquisitions.

Another may use a trailing period.

Another may leave the field blank when one component is unavailable.

The same label can represent different formulas.

This can create inconsistent comparisons across companies or countries.

The safest approach is often to preserve the raw components and calculate the desired metric through a documented rule.

That does not eliminate all uncertainty.

It makes the assumption visible and reproducible.

Negative signs can reverse the conclusion

Cash-flow statements frequently represent outflows as negative numbers.

A capital-expenditure field may already be negative.

If the system calculates:

Operating cash flow minus capital expenditures

while capital expenditures are stored as a negative number, it effectively adds the expenditure.

Free cash flow becomes overstated.

A company spending heavily may appear to generate enormous excess cash.

This is a small technical mistake with a major investment consequence.

Sign conventions need to be understood rather than guessed.

Units can create thousandfold errors

Financial data may be reported in:

• Dollars

• Thousands of dollars

• Millions of dollars

• Pence

• Cents

• Local currency

• Converted currency

If a provider reports revenue as 500 because the value represents $500 million, another system may interpret it as $500.

If debt is stored in thousands while assets are stored in whole units, the leverage ratio becomes meaningless.

Unit errors often produce extreme ratios.

Those extreme ratios can rise to the top of a stock screen because they look exceptional.

The system may mistake a scaling error for a rare opportunity.

Extreme results should trigger validation, not immediate excitement.

Stale prices can create yesterday’s opportunity at today’s date

Small or foreign securities may trade infrequently.

A provider may show the last available price even when that price is several days old.

The financial database uses current information.

The price belongs to an earlier market.

If the stock moved sharply afterward, the valuation is no longer available.

A strategy can appear to buy at a price that existed only before the relevant information became public.

Price freshness matters.

The system should know:

• The trade date

• The market calendar

• Whether the market was open

• Whether the price was stale

• Whether enough volume traded

• Whether the investor could realistically transact

A number printed in a price field is not automatically an executable price.

Adjusted and unadjusted prices answer different questions

Unadjusted prices show what one share traded for at the time.

Adjusted prices account for events such as splits and dividends.

Both can be useful.

Problems appear when they are mixed.

A strategy may calculate entry prices using adjusted data but compare them with unadjusted exits.

Dividends may be counted twice.

A split may appear to create a large loss.

Historical returns become distorted.

The system should use a consistent price policy and document what the selected series represents.

Delisted companies can disappear from the market’s history

A modern data source may contain only companies that still trade today.

Failed, acquired, bankrupt, or delisted businesses may be missing.

A strategy tested on this population receives an easier market.

Many of the worst outcomes have already been removed.

The remaining companies appear healthier.

Financial ratios may seem more predictive because the population was filtered by survival before the strategy began.

This is not merely a missing-data problem.

It changes the investment universe.

A reliable historical system must remember the companies that failed, not only the companies that survived.

Incorrect classifications create false comparisons

A company can have correct financial data and still be evaluated incorrectly.

A bank may be treated as an ordinary operating company.

A real estate trust may be judged using standard net income.

A miner may be rewarded for unusually high profits at the peak of a commodity cycle.

The numerical inputs are real.

The interpretation is wrong.

This is why raw data and investment decisions should remain separate:

The database preserves the evidence.

The strategy decides which ruler belongs to each business.

Extreme values are often data problems before they are opportunities

When a company looks dramatically cheaper than everything around it, there are several possible explanations.

The market may be wrong.

The company may be extremely risky.

The business may be cyclical.

Or the data may be broken.

The correct first reaction is not excitement.

It is validation.

Questions should include:

• Does another provider show the same value?

• Does the original filing support it?

• Are the units correct?

• Are the currencies aligned?

• Is the price current?

• Is the share count accurate?

• Did a split or merger occur?

• Are the earnings annual or quarterly?

• Was a one-time gain included?

• Does the ratio remain attractive after correction?

A genuine bargain should survive inspection.

A fake one usually disappears when the pipeline is repaired.

Cheap screens are especially vulnerable

Value strategies search for unusual relationships between price and financial strength.

That makes them sensitive to data errors.

A growth screen may be distorted by one incorrect growth rate.

A value screen can place the most broken records at the very top because errors often create extreme cheapness.

Examples include:

• Missing debt interpreted as zero

• Market capitalization understated by stale share counts

• Earnings overstated by duplicated periods

• Foreign prices misread by a factor of 100

• One-time gains treated as recurring profit

• Negative capital expenditure handled with the wrong sign

A screen designed to find outliers will also find outlier errors.

The stronger the apparent bargain, the stronger the need for verification.

The screener should reject suspicious data

A stock screener should not merely apply financial thresholds.

It should also protect itself from questionable inputs.

A company might be quarantined when:

• Important fields disagree across sources

• Valuation ratios are economically impossible

• Prices are stale

• Currency is uncertain

• Share-count history is missing

• Filing periods overlap

• Corporate actions remain unresolved

• The company identity is ambiguous

This does not prove the company is unattractive.

It proves the system cannot yet evaluate it honestly.

The screener’s purpose is to reduce avoidable mistakes, not force every company into a ranking.

Rejecting unreliable evidence can be just as important as rejecting weak economics.

Data-quality scores should influence confidence

Suppose two companies receive the same investment score.

The first has:

• Ten years of consistent filings

• Verified prices

• Stable currency mappings

• Clear share-count history

• No unresolved contradictions

The second has:

• Missing periods

• Estimated values

• Uncertain ticker mappings

• Stale prices

• Several provider disagreements

The final numerical score may be identical.

The confidence behind it should not be.

A data-quality layer can help distinguish between:

• Strong conclusion from strong evidence

• Tentative conclusion from weak evidence

The second company may deserve investigation rather than immediate rejection.

It should not be treated as equally certain.

Provenance creates a chain of evidence

Every important value should carry context.

The system should know:

• Which provider supplied it

• Which filing it came from

• Which company identity it belongs to

• Which period it describes

• When it became available

• Which currency and unit it uses

• Whether it was reported or calculated

• Which transformations were applied

• Whether validation checks passed

This information is called provenance.

It allows a final investment score to be traced back to its ingredients.

Without provenance, correcting an error becomes difficult.

The system may know that a ratio is wrong without knowing where the problem entered.

Reproducibility is an investment feature

A trustworthy result should be reproducible.

Given the same data, rules, and date, the system should reach the same conclusion.

If it cannot, the historical evidence is unstable.

Reproducibility allows questions such as:

• Why did this company pass yesterday?

• Which filing changed the score?

• Did the company change, or did the pipeline change?

• Which strategies used the incorrect value?

• Did the correction alter historical selections?

• Does the original investment thesis still exist?

This is not merely good software engineering.

It helps prevent capital from being allocated based on conclusions that cannot be explained.

Validation should happen before ranking

The pipeline should not calculate every possible ratio and hope that the final score hides the bad inputs.

Validation should occur earlier.

A reasonable sequence is:

1. Confirm the company identity.

2. Confirm the exchange and trading currency.

3. Verify filing dates and reporting periods.

4. Normalize units.

5. Resolve splits and corporate actions.

6. Check share-count consistency.

7. Detect duplicates and contradictions.

8. Preserve missing values honestly.

9. Calculate strategy-specific features.

10. Rank only the companies with usable evidence.

This keeps bad inputs from becoming sophisticated-looking outputs.

Manual inspection still has a role

Automation is necessary when studying thousands of companies.

But unusual opportunities deserve manual verification.

A human can open the filing, inspect the price history, compare providers, and examine corporate actions.

The system’s job is not to eliminate judgment.

It is to direct judgment toward the cases where it matters most.

The most attractive candidates should face more scrutiny, not less.

A company that appears ordinary may pass through standard checks.

A company that appears almost impossibly cheap should be treated like a software result that fails a sanity test.

Bad data can also hide real opportunities

Data errors do not only create fake bargains.

They can conceal genuine ones.

A company may appear excessively expensive because:

• Its price was interpreted in the wrong units

• Earnings were missing

• A filing was mapped incorrectly

• A share split was mishandled

• Cash flow was attached to the wrong period

The screener rejects the company.

The opportunity disappears from the research queue.

This is why data quality should not be viewed only as protection from false positives.

It also protects against false negatives.

A better database does not guarantee better returns.

It creates a fairer opportunity set.

The investment system must distinguish three failures

When a company performs poorly, several things may have happened:

1. The data was wrong.
   The opportunity never existed as measured.

2. The interpretation was wrong.
   The data was correct, but the strategy misunderstood it.

3. The future changed.
   The evidence and reasoning were reasonable, but an uncertain outcome went badly.

These failures require different responses.

A data error requires pipeline repair.

An interpretation error requires strategy improvement.

An uncertain outcome may require no rule change at all.

Without clean separation, every loss can be blamed on the strategy—or excused as bad luck—without understanding the true cause.

The goal is not perfect data

No financial database will be perfect.

Companies report differently.

Providers make mistakes.

Currencies change.

Corporate actions create complications.

Historical records remain incomplete.

The correct objective is not flawless knowledge.

It is controlled uncertainty.

The system should know where evidence is strong, where it is weak, and where it is missing.

It should preserve the original records, document transformations, quarantine suspicious cases, and avoid pretending that every number deserves equal trust.

A fake opportunity is worse than no opportunity

An empty screen can feel frustrating.

A database full of apparently cheap stocks feels productive.

But activity is not the goal.

A fake investment opportunity consumes:

• Research time

• Attention

• Emotional energy

• Backtesting capacity

• Confidence

• Potentially real capital

It can influence future rules because the researcher tries to explain a pattern that came from an error.

It can even make a broken strategy look successful if the same bad data affects the backtest.

Sometimes the safest and most accurate conclusion is:

This company cannot yet be evaluated reliably.

That is better than manufacturing conviction from corrupted evidence.

The final lesson

Markets contain genuine mispricings.

Businesses do become misunderstood.

Strong companies are sometimes sold too cheaply.

But the most extraordinary bargain in a database may not be a market failure.

It may be a data failure.

Before asking why other investors missed the opportunity, the system should ask whether the opportunity survives basic verification.

Are the company, price, currency, period, share count, and financial statements aligned?

Were the values actually available at the time?

Are missing fields still missing, or were they turned into favourable assumptions?

Can the result be reproduced from the original evidence?

A reliable investment process does not begin by trusting the most exciting number.

It begins by trying to prove that the number is real.

Bad financial data creates fake investment opportunities.

Good data does not tell us what to buy.

It gives us a market that actually existed—and a fair chance to make an honest decision inside it.

Subscribe now

Share

Share Fungal Intelligence for Stocks

Leave a comment

A blank field prevents a ratio from being calculated. A company disappears from a stock screen. The analyst moves on to the next business.

But missing data is not always meaningless.

Sometimes the absence of a number tells us something important about the company, the provider, or the reliability of the analysis.

That is why my system should not simply erase missing data or quietly replace it with zero.

It needs to ask why the information is missing.

A blank value is not zero

Suppose a company has no reported free-cash-flow figure.

That does not mean its free cash flow was zero.

The value could be missing because:

• The company did not publish enough information

• The provider failed to collect the filing

• The company recently changed reporting formats

• The ticker was mapped incorrectly

• The cash-flow statement was incomplete

• The company is too new to have enough history

• The calculation requires another missing field

These explanations have very different meanings.

Replacing the blank with zero would create false information.

It could make a profitable company look weak or make a risky company appear easier to evaluate than it really is.

Unknown and zero are not the same thing.

Missingness can reveal weak infrastructure

Sometimes the company is not the problem.

The data pipeline is.

A provider may have excellent coverage in the United States but weaker coverage in another country.

A foreign ticker may use a different exchange suffix.

A company may trade in one currency while reporting in another.

A filing may exist, but the system may have attached it to the wrong security.

In these cases, missing data identifies a weakness in the research infrastructure.

That is useful.

A blank cell can point toward a broken route, an incomplete provider mapping, or a failed transformation.

Ignoring it would allow the same error to contaminate future research.

Missingness can also reveal company risk

Other times, the missing information belongs to the company itself.

Some businesses report clearly and consistently.

Others change definitions, publish incomplete statements, delay filings, or make it difficult to connect one reporting period to another.

A company that is difficult to measure may also be difficult to trust.

This does not mean every missing field proves that management is hiding something.

There are innocent explanations.

Smaller companies may have fewer reporting resources. Different countries may require different disclosures. Certain industries naturally present their accounts differently.

But poor transparency should not be invisible.

If two otherwise similar companies exist, and one provides a long, consistent history while the other repeatedly produces gaps and contradictions, that difference matters.

Data quality can become part of investment quality.

Screeners hide the rejected population

Imagine creating a screen that requires positive free cash flow, low debt, and five years of revenue history.

The screener returns 200 companies.

It is tempting to assume those are simply the 200 businesses that passed the rules.

But what happened to everything else?

Some companies genuinely failed the financial conditions.

Others may have disappeared because one required number was unavailable.

Those are not the same outcome.

A company with excessive debt was evaluated and rejected.

A company with missing debt information was never fully evaluated.

When both disappear from the results, the investor cannot distinguish a deliberate rejection from a data failure.

That creates a hidden bias.

The final list may favour companies, industries, and countries with better data coverage rather than those with better economics.

Missing data can distort backtests

This problem becomes more dangerous when testing historical strategies.

Suppose the companies with complete financial histories are also the larger, older, and more successful businesses.

If incomplete companies are removed from the test, the dataset becomes cleaner than the real market was.

Failed companies may vanish.

Newer companies may vanish.

Businesses from poorly covered exchanges may vanish.

The strategy is then tested on a population that was partly selected by data availability.

Its performance may look stronger because the hardest companies were removed before the strategy had to judge them.

This is similar to survivorship bias.

The missing records can quietly reshape the past.

Filling every gap can be just as dangerous

One possible solution is to estimate missing values.

Sometimes that is reasonable.

A short gap in a stable time series might be estimated carefully. A known accounting relationship may allow a value to be reconstructed from other reported fields.

But estimation creates its own risks.

The system may become confident about information that was never actually reported.

A few assumptions can gradually turn into a fictional financial history.

The more estimated values a company contains, the less independent evidence remains.

My system therefore needs to distinguish among:

• Reported values

• Calculated values

• Estimated values

• Missing values

• Invalid or contradictory values

All five categories may contain numbers—or the absence of numbers—but they do not deserve the same level of trust.

Data quality should affect confidence

Imagine two stocks receive the same score.

The first score is based on ten years of consistent filings, stable definitions, and complete financial statements.

The second is based on scattered reports, reconstructed values, and several missing periods.

Treating those scores as equally reliable would be a mistake.

The final number may be identical.

The evidence behind it is not.

This suggests that data quality should influence how much confidence the system places in a company’s ranking.

A business should not automatically receive a bad score just because information is missing.

But it may deserve:

• A lower confidence level

• A separate warning

• A stricter margin of safety

• Exclusion from certain comparisons

• More manual investigation

• Quarantine until coverage improves

The goal is not to punish uncertainty.

It is to stop uncertainty from pretending to be precision.

The pattern of missingness matters

One isolated blank may not mean much.

A repeated pattern can mean more.

Does the company consistently lack cash-flow information?

Are share-count figures missing during periods of heavy dilution?

Do gaps appear around major acquisitions?

Are certain countries or exchanges systematically underrepresented?

Does one provider fail while another has complete coverage?

The pattern helps separate random technical errors from structural problems.

In biology, one dead leaf tells us little.

A repeated pattern of damaged leaves across the whole tree suggests a deeper issue.

Financial data works similarly.

The system should remember why

A strong database should not store only the value.

It should also preserve information about the value.

Where did it come from?

When was it reported?

Was it calculated?

Was it converted between currencies?

Did a provider return no data?

Did validation fail?

Was the value rejected because it was impossible or contradictory?

This creates a chain of evidence.

Instead of seeing only a blank cell, the system can understand the state of knowledge surrounding that cell.

That makes future repairs possible.

It also prevents one missing number from being silently transformed into a false conclusion.

Honest uncertainty is valuable

Investing systems often try to turn everything into a clean score.

Clean scores are comfortable.

They make companies easy to rank and decisions easy to explain.

But the real world is not always complete enough to support that confidence.

Sometimes the correct answer is:

We do not know enough yet.

That is not a failure of analysis.

It is an honest result of analysis.

A system that recognizes uncertainty may reject more opportunities.

It may look less decisive.

But it is also less likely to build confident decisions on imaginary evidence.

The absence is part of the evidence

Financial data tells us what a company reported.

Missing data tells us where our knowledge ends.

That boundary matters.

A blank field may reveal a broken provider connection, an unusual accounting structure, a young company, weak disclosure, or a deeper reliability problem.

The correct response is not always to reject the company.

It is to investigate the cause and reduce confidence until the uncertainty is understood.

The numbers that exist help us measure a business.

The numbers that are missing help us measure how much we should trust that measurement.

That is why missing data is information.

Subscribe now

Share

Share Fungal Intelligence for Stocks

Leave a comment

They choose a few conditions—low valuation, strong growth, manageable debt—and receive a list of companies that appear to match.

That is useful for finding ideas.

But I do not want my investment system to depend entirely on someone else’s finished answers.

I want access to the evidence underneath them.

That is why I’m building a fundamental database.

A screener gives you conclusions

A screener might tell you that a company has:

• A price-to-earnings ratio of 12

• Revenue growth of 8%

• A debt-to-equity ratio of 0.7

• Positive free cash flow

But those numbers have already passed through several hidden decisions.

Which financial period was used?

Were currencies converted?

Were restatements included?

How were missing values handled?

Was free cash flow taken directly from a provider, or calculated from other fields?

Did the provider use annual results, trailing results, or the latest quarter?

Two screeners can show different numbers for the same company because their definitions and data pipelines differ.

The final ratio may look precise.

The process behind it may not be visible.

A database lets me inspect the ingredients

I think of financial data like fruit collected from thousands of trees.

A screener hands me a prepared meal.

A database lets me inspect the fruit before deciding what to cook.

I can store revenue, cash flow, debt, share count, assets, margins, and reporting dates separately.

Then I can calculate the investment metrics myself.

That matters because my strategy will continue changing.

Today I may care about free-cash-flow yield.

Later I may want to study dilution, deterioration, capital efficiency, or reporting consistency.

When the raw ingredients are preserved, I can rebuild the measurements without collecting everything again.

Historical testing requires historical truth

A strategy should be tested using only the information that would have been available at the time.

That sounds obvious, but it is easy to violate.

Suppose a company later restates its financial results.

A modern screener may show the corrected historical number.

But an investor making a decision years earlier would not have known that correction yet.

Testing a strategy with updated information can make the past look cleaner and more predictable than it really was.

This is a form of look-ahead bias.

The system quietly learns from information that had not yet entered the world.

A proper historical database should preserve filing dates, reporting periods, and the sequence in which information became available.

Otherwise, the backtest may be evaluating an imaginary investor with access to the future.

Missing data should not disappear

Screeners often make missing information easy to ignore.

A company may simply vanish from the results because one required field is unavailable.

That creates a hidden selection process.

The investor sees the companies that passed, but may not see why thousands of others were excluded.

In my system, missing data needs to remain visible.

Was the company missing one filing?

Was the provider unable to map the ticker?

Did the company report in a different format?

Was the business too new?

Was the data genuinely unavailable?

These are different problems.

Treating them all as a blank cell would destroy useful information.

Sometimes missing data is just a technical error.

Sometimes it is evidence that the company is harder to understand, less transparent, or riskier to analyze.

Global investing makes the problem harder

My system examines companies from several countries.

That means the database must deal with different currencies, exchanges, reporting conventions, fiscal calendars, and accounting structures.

A company may report its financial statements in one currency while its shares trade in another.

Some prices may be quoted in minor currency units.

A company’s local share price may rise while its U.S.-dollar return falls because of exchange-rate movement.

A generic screener may handle these issues correctly.

But unless I understand the process, I cannot verify the result.

Building the database forces the assumptions into the open.

The database is not the strategy

Collecting more data does not automatically produce better investments.

A large database can still support a terrible strategy.

The database stores observations.

The strategy decides what those observations mean.

Keeping those layers separate is important.

It allows me to improve the scoring system without rewriting the historical record.

It also prevents the database from being shaped around one preferred conclusion.

The warehouse should preserve reality as faithfully as possible.

The investment system can then test different interpretations of that reality.

Why not simply trust a provider?

I still rely on outside providers.

Building a database does not mean personally typing every financial statement into a spreadsheet.

It means keeping durable copies of the raw information, checking coverage, documenting transformations, and calculating the final investment features through a process I control.

Providers remain part of the supply chain.

They just do not become the entire factory.

The boring work creates the foundation

Building a database is slower than opening a screener.

It involves ticker mapping, filing history, currencies, missing values, duplicate records, provider failures, and many other problems that are not exciting to write about.

But every advanced part of the investment system will depend on this foundation.

Optimization cannot repair incorrect financial history.

Machine learning cannot create truth from inconsistent labels.

A beautiful backtest cannot rescue contaminated data.

In programming, unreliable inputs create unreliable outputs.

In investing, the same rule applies.

What I am really building

The goal is not merely to collect a large number of financial records.

The goal is to build a chain of evidence.

I want to know:

• Where each number came from

• When it became available

• What transformations were applied

• Which values are missing

• Which comparisons are valid

• Whether the same result can be reproduced later

A screener helps answer:

Which stocks match these rules today?

My database is meant to answer a deeper question:

What did the financial world actually look like at each point in time, and what could an investor reasonably have known?

That is the foundation I want before trusting any strategy built on top of it.

Subscribe now

Share

Share Fungal Intelligence for Stocks

Leave a comment