العربية

MethodologyALQA RESEARCH

We reject most strategies we test.That is what testing is for.

ALQA portfolios follow programmed rules that determine which funds to invest in, how much to allocate to each and when those allocations change.

How do we test these rules?

Before accepting a strategy, we test its performance and risks across different market conditions, accounting for trading costs and measuring the impact of delayed execution. We evaluate the results against acceptance criteria set before testing begins. We then test the strategies together within the portfolio. During operation, the rules are applied automatically and any change is documented in a new version.

Explore the testing journey
RESEARCH / VALIDATION / OPERATIONScroll to explore the stages

Every test has a question.Every result has a prior criterion.

Randomized versions each portfolio must outperformWe compare each portfolio with randomized versions of itself to test whether its rules add value beyond chance.
1,000
Periods within the research sampleTo assess whether results hold across different periods, rather than depend on one favourable stretch.
4
Evaluation outside the research sampleTo assess the frozen rules on data not used to develop them, without adjusting the rules after seeing the results.
1
Trading-cost levelsThe strategy must remain viable at the highest tested cost level.
3
Reference threshold for alphaA published reference for assessing the alpha t-statistic against the market model and a four-factor model.
t > 3
Restart drills per releaseEach release must pass eight drills to verify that the system resumes operation correctly after a restart.
8
Consecutive trading sessions meeting reconciliation criteriaRequired on the automated execution platform, with two reconciliation checks per session and a maximum permitted difference of one share.
21
Discretionary decisionsEvery decision follows a predefined rule and is executed automatically.
Zero
Documents with publicly verifiable timestamps16 rule files and 127 specifications, with publicly verifiable timestamps.
143
Registration policy

Every criterion and its numerical threshold is registered before the corresponding test runs. Amendments are dated in the specification.

View the registration recordsThe records identify prior calculations and amendments after results, and explain the limits of the recorded chronology.
View documentation fingerprints · SHA-256
8849a3261342daee051371f1fe7d0f274a65e2d827af87957fe6102e7ee975385263b478c34dca1d0a455a7ac922de5211766ad11f41dea1ece33ac49ef9a901aad70330d4f37783632f83a26ab3c64e96a10b655abd044392710bccc2132430f3d2f3b4c5600e3f9e69638f051ec684b9efc1b577c3aea8de2cd9530199192eb7b378e54e14e512a9902862144650311faeafab09b270b76d3957833ae78746

The research process

Discover how we test.

Choose a stage and try the idea yourself. Each example explains one part of the methodology.

Six connected stagesSwipe to explore →

Stage 01 / 06Before testing

We define the test before we see a result.

Rules, data, costs and acceptance criteria: we define them in advance, then save the specification and its digital fingerprint in the research record. Every later change is dated.

Change a detail. Watch the fingerprint.

Illustrative example
Example specificationEXAMPLE–01
Record typeTest conditions

Saved version fingerprint SHA-256

…

Current version fingerprint

…

Calculating the fingerprint…

Change the number of periods and compare the fingerprints. The example saves the version only within this page.

Where does a timestamp come in?

The fingerprint checks whether versions match. An external timestamp adds evidence that a version existed by a documented date. This example calculates a fingerprint only; it does not issue a timestamp.

The example data is illustrative. The fingerprint is calculated from the example in your browser.

Stage 01 / 06

PORTFOLIOS & CONSULTING

Explore our portfolios.Or take a closer look at yours.

Explore six portfolios built around defined rules, or work with ALQA to understand your portfolio’s allocation, risks and concentration.

Explore portfoliosDiscuss your portfolio

Investing involves risk, including loss of capital. Historical test results are hypothetical and do not represent the performance of any actual account. Past or hypothetical results do not predict future results. Client results differ from model results because of differences in execution, timing, account size and costs.

Methodology / Reading guide

The detail behind each stage.

01 / 06

We define the test before we see a result.

Conditions first

We define the strategy’s rules, the data it may use and when that data becomes available, costs, the test period and acceptance and rejection criteria. We also explain why we expect the strategy to add value.

A version we can return to

We save this specification and its digital fingerprint in the research record before the first formal test. Exploratory runs before the specification is fixed do not count as formal test results. Every later change is dated, keeping each result tied to the conditions under which it was tested.

What does a timestamp add?

A digital fingerprint lets us check whether two versions match. An external timestamp adds evidence that a particular version existed by a documented date; it does not prove that the research is correct or that the test record is complete. This page’s interactive example calculates a fingerprint only. It does not issue a timestamp.

Results are measured against criteria set in advance, and later changes remain visible in the record.

02 / 06

Does the timing of decisions add value?

A thousand versions to compare

We replay the strategy’s same trades on random days across 1,000 versions, keeping trade count and costs fixed and using fixed randomisation settings so the test can be reproduced. We compare the original rule with these versions.

What does the result mean?

If the original rule does not outperform the vast majority of the random versions, it fails the acceptance criterion: it has not shown enough evidence that its timing adds value beyond the assets it held. This alone does not mean those assets explain every result the strategy achieved.

We want to know whether decision timing adds value beyond the returns of the assets themselves.

03 / 06

Years that played no part in development.

Four periods within the research

We divide the research period into four periods so the result does not depend on one favourable period. The most recent years stay outside development until the portfolio rules are fixed.

One evaluation after the rules are fixed

We run this test once against criteria set in advance and publish its result alongside the research results, whatever the outcome, without retuning the rules afterwards. A short period alone cannot establish an investment edge.

The limits of what we learn

If the reserved period’s result is used to change the rules, that period has become part of development. Running the test again does not make the data unseen again. Nor does a historical result put a limit on what the portfolio could lose in the future.

The rules are tested on data that was not used to select or improve them.

04 / 06

Do our tools detect what they should?

Testing the test itself

We add a small, known edge to a strategy with no edge and test whether our tools detect it. We measure how often strategies with no edge are accepted by mistake, check that deliberate errors are detected, and recalculate through a separate path.

Higher costs and delayed execution

We test three cost levels, and passing the toughest is a condition of acceptance. We delay execution of every decision by one trading session to measure the effect on results.

A history that includes crises

Historical testing includes the 2008–2009 global financial crisis, with substitutes declared in advance for funds that did not yet exist. Rejected strategies stay in the record; renaming them does not erase their rejection.

We need to know what our tests can detect and when they might accept a strategy by mistake.

05 / 06

The components together, in one portfolio.

The whole portfolio

We combine accepted strategies at fixed weights for each strategy, alongside bonds, and test the whole portfolio through one engine and one account. The combined portfolio faces the same tests and acceptance criteria.

Does each component add value?

We review the effect of removing each component in turn and compare the chosen weights with equal weights. We judge the result by testing the whole portfolio, not by adding up its components’ separate results.

Reducing exposure during a drawdown

As the portfolio falls from its peak, exposure is reduced in stages and restored only at a new peak. The released funds go into bonds. This mechanism does not cap losses.

Execution and capacity constraints

The portfolio does not rely on borrowing or leverage at portfolio level. It may include funds that use leverage internally, which is disclosed. We set a minimum account size with whole-unit purchasing constraints in mind, estimate portfolio capacity using liquidity and execution assumptions, and review those assumptions.

Strategies succeeding on their own is not enough to judge how they perform together in a portfolio.

06 / 06

Every decision has rules. Every change has a version.

Testing operations

We run the portfolio in a simulated account with live market data and test restarts and emergency stops against criteria set in advance. A specified number of consecutive sessions must pass without failure.

Reviewing decisions

We reconcile the account with decisions several times a day and independently recalculate them weekly, decision by decision. We check that the operating version matches the approved version.

Separating research from operations

Research and operations are separate, with independent permissions; the research path cannot write to the operating environment. Any portfolio design change, whether to rules, approved weights or the fund universe, receives a documented, approved version with a date and clear reason.

A record that retains what happened

Every error is recorded with a reference to the original entry. A correction is added to the record rather than silently replacing the old entry.

Decisions remain tied to the rules that were tested, while errors and changes stay visible in the record.