International Quantitative Innovation Challenge (IQIC)
International Quantitative Innovation Challenge (IQIC) is an international quantitative finance competition for high school students who want to apply mathematics, programming, data analysis, and financial modeling to a real quantitative problem.
What students actually do
Students translate a question into a testable method. They define inputs, record assumptions, prepare data, build a model, evaluate what happened, and explain limitations instead of treating a result as a promise.
Skills involved
Useful preparation includes probability, statistics, Python, data cleaning, visualization, model evaluation, and plain-language communication. Students do not need to arrive as experts; they need a habit of making work reproducible.
How teams work
A strong team divides research, data, modeling, and writing while keeping one shared record of decisions. Every member should be able to explain the question, assumptions, method, and limits.
What students produce
A useful submission makes its reasoning inspectable: a clear problem statement, documented dataset, reproducible code or calculations, results, and a candid limitations section.
How evaluation works
IQIC evaluates the quality of reasoning, transparent methodology, reproducibility, interpretation, and communication. Official scoring, stages, dates, and submission rules will be published only when final approved rules exist.
Preparation
Start with a small project. Learn quantitative finance foundations, practice Python, run a simple backtest without leaking future information, and write down what the exercise cannot establish.
Frequently asked questions
IQIC is built for high school students. Team size, eligibility, geography, dates, permitted tools, intellectual-property terms, and final format require official rules and are not inferred here.
Continue learning
Explore quantitative finance, Python for quantitative finance, and backtesting for beginners before turning an idea into a competition project.
Who IQIC is for
IQIC 2027’s current operating charter defines the event for students ages 13–17 worldwide. Entry is planned to be free. Teams may be solo or include one to four students, including cross-school and cross-country teams. English is the working language and live programming is oriented around Pacific Time. The final age-measurement date remains unresolved, so students should wait for published rules before relying on age eligibility.
Competition format and mechanics
The current format is an open online challenge rather than a selective application. Every team receives one common market-oriented quantitative decision problem with optional sub-directions. The planned build period is approximately 14 days, with optional structured checkpoints. This means teams have time to research, prototype, test, revise, and explain—not merely race through a weekend.
What a quantitative decision system means
A quantitative decision system takes stated inputs and produces a recommendation, forecast, ranking, allocation, risk assessment, or other decision output. It can use statistics, optimization, machine learning, simulation, external APIs, or a simpler rule-based method. Technical novelty alone is not enough. The system must connect to the shared challenge, use evidence responsibly, and make the team’s reasoning inspectable.
Teamwork and roles
Effective teams do not split into isolated “coder” and “writer” roles. One student may lead data preparation, another model design, another validation, and another explanation, but each should understand the central question and assumptions. Keep decisions in a shared log. Record dataset source, transformation, model version, test period, and change rationale so the final work can be explained under questioning.
Submission expectations
The charter requires a real predictive or decision-making quantitative system. A credible project normally includes a problem statement, system diagram or method description, documented data, reproducible code or calculations, evaluated results, and an honest limitations section. Exact submission format, repository requirements, file limits, permitted tools, and intellectual-property terms are not yet final rules and will not be invented on this page.
Evaluation and finalist selection
After submissions close, judges are planned to select exactly 10 finalist teams. The charter prioritizes the quality of reasoning, transparent methodology, reproducibility, interpretation, communication, and relevance to the challenge. The public finals format is planned as an eight-minute presentation plus seven-minute judge Q&A for each finalist, followed by one overall IQIC Champion. The final rubric and weighting must be published with official rules.
Tools, data, and AI
Teams may use approaches such as machine learning, agents, forecasting, optimization, risk systems, market intelligence, external APIs, and proprietary models within the common problem. Good use of a tool means disclosing its role and checking its limits. Do not submit a black box that cannot be explained. Tool permissions, data licenses, citation rules, and AI disclosure requirements need official release before registration.
How to prepare
Start with one short project before competition season. Use quantitative finance foundations to learn how a model frames a question. Use Python to make an analysis repeatable. Use backtesting to understand why historical evidence has limits. Then write a one-page methods note that names the question, data, assumptions, evaluation, and likely failure modes.
Frequently asked questions
Is IQIC an investing contest? No. It is a quantitative-computing challenge with finance as its inaugural flagship application. Can students work alone? Yes; current format allows teams of one to four. Are dates final? No; the charter defines format but not public event dates. Can students use AI? The charter anticipates advanced tools, but exact allowed-use and disclosure rules must be published officially. What happens after submission? Judges review entries and select 10 finalist teams for public championship presentations.
From idea to evidence
A useful project sequence is deliberately ordinary. First, rewrite the challenge as a measurable decision question. Second, identify the data required and whether each field exists at decision time. Third, build the smallest method that could answer the question. Fourth, compare it with a simple baseline. Fifth, inspect errors and failure cases. Sixth, preserve code, parameters, and assumptions. This workflow is valuable whether the eventual method is a spreadsheet calculation, optimization model, machine-learning pipeline, or agent-assisted research system.
Data integrity and reproducibility
Quantitative work fails quietly when raw inputs move, cleaning steps are undocumented, or a model receives hidden future information. Teams should retain original files or stable source links, describe missing-value and outlier decisions, separate development and evaluation periods, and state every transformation. Another student should be able to trace a chart back to its input. If exact replication is impossible because of a proprietary source or API, explain what cannot be shared and provide the closest reproducible substitute.
Presenting a result honestly
Good final presentations answer five questions: What decision does the system support? What information did it use? How did the team turn that information into an output? What evidence suggests the approach is useful under its stated conditions? Where does it break? Present a baseline beside the preferred method, name uncertainty, and avoid unsupported causal or financial claims. Reviewers can assess a simple, transparent project more confidently than a sophisticated system no one can explain.
For educators and mentors
Students benefit most when adults ask questions rather than supply the answer: What assumption changed this result? How would the method behave on unseen data? Which source created this field? What would make the conclusion weaker? Encourage teams to work in small milestones and keep a shared methods log. IQIC is an educational build challenge; the purpose is better quantitative reasoning, responsible tool use, and clear communication—not real-money trading advice.
How teams can test their work
Testing does not need to mean a complicated benchmark suite. Begin by stating what a simple alternative would do. If a model sorts opportunities, compare it with a transparent rule. If it forecasts a value, compare errors against a simple historical baseline. Check whether the result changes across periods, assumptions, or subsets of the data. Save both favorable and unfavorable cases. These checks help a team distinguish evidence from a story produced by one convenient sample.
Communication under judge questions
Prepare for questions that challenge the method rather than celebrate the output. A reviewer may ask why a variable was included, how missing values were handled, whether a result used unavailable information, or how a system would react when assumptions fail. The strongest answer is specific and calm: identify the design choice, explain its consequence, and name what the team would change next. Rehearse this explanation with a teammate who did not build that part of the project.
What success looks like before finals
A successful IQIC project is not defined only by finalist selection. A team should leave with a documented method it can rerun, a clearer understanding of uncertainty, and a concise explanation of its choices. Students can use that work as a foundation for future research, a school presentation, or a more ambitious competition project. Keep the project’s scope narrow enough that every claim can be defended with evidence.
What IQIC is not
IQIC is not a stock-picking contest, a standardized exam, or a generic AI-trading weekend. Teams are not rewarded for claiming certainty about markets. The inaugural application uses a market-oriented problem because it gives students a demanding setting for quantitative computing. The underlying skill is broader: frame a decision, model uncertainty, test evidence, communicate limits, and improve the system when a result does not hold.