Fast Optimization of Forex Quant Program
Budget / Salary$10–30
TypeFreelance project
LocationRemote
Posted57 minutes ago
$10 project max. This can be finished in a few hours max. I need someone to work fast.
Title: Speed Optimization and Completion of Forex Non-Print Quant Research Program
I have an existing Windows-based, three-part quantitative research program designed to discover and validate trading strategies for OANDA forex markets. The program is functional, but its historical tick-data backfill is too slow and produces excessive timeout and service-error messages.
I need an experienced Python, market-data, and quantitative-research developer to optimize and complete the existing program. I am not requesting a rebuild from scratch.
The program uses historical BID and ASK tick data to derive Non-Print events and Line Break market structures. I want it to collect as much legitimate historical data as can reliably be obtained, as quickly as possible, while preserving the exact order and integrity of the data.
I am not requiring a particular historical-data provider. The developer may select or combine appropriate legitimate sources, provided the data is genuine BID/ASK tick or quote data suitable for deriving the existing Non-Print structures. Candle, OHLC, interpolated, fabricated, randomly generated, or synthetic data is not acceptable.
Required backfill improvements:
* Obtain as much usable historical BID/ASK tick data as possible.
* Maximize sustained download speed without overwhelming providers.
* Use asynchronous downloading, connection reuse, intelligent batching, and adaptive concurrency.
* Automatically adjust the worker count based on latency, throttling, and failure rates.
* Process and save completed data immediately instead of waiting for an entire batch.
* Prevent one slow request from blocking every other completed request.
* Checkpoint every completed segment.
* Resume from the exact stopping point after closure, crash, internet loss, or Windows restart.
* Never redownload data that has already been verified and saved.
* Retry temporary failures through an organized repair queue.
* Distinguish genuine market closures or unavailable history from temporary connection failures.
* Validate timestamps, BID prices, ASK prices, sequence order, duplicates, malformed records, and crossed markets.
* Maintain clear provenance if more than one compatible historical source is used.
* Continue accumulating new OANDA forex data after the historical backfill.
* Preserve all existing Non-Print, Line Break, feature-engineering, strategy-discovery, validation, and QuantConnect LEAN functionality.
The program should not display continuous raw timeout, HTTP, connection, or service-error messages to the user. Temporary provider problems should be handled internally through retry logic, backoff, adaptive concurrency, and repair queues.
The visible interface should show simple, understandable status information:
* Running, paused, completed, or repairing.
* Historical date range requested.
* Historical date range successfully collected.
* Completed segments versus remaining segments.
* Total BID/ASK ticks saved.
* Current download speed.
* Current worker count.
* Retry-queue size.
* Data gaps still requiring repair.
* Elapsed time.
* Estimated time remaining.
* Whether enough data is available to begin research.
A genuine unrecoverable problem must produce one concise, actionable explanation. The application must not freeze, silently stop, repeatedly flood the log with the same errors, falsely report completion, or discard downloaded progress.
Fast preliminary result:
I want the application to obtain a useful recent research window first, run the complete strategy-discovery pipeline, and show me a preliminary result without forcing me to wait for the maximum historical archive.
After that preliminary research result is available, the program should be capable of continuing its historical expansion and live-data accumulation without erasing previous work. Research can then be refreshed as more history becomes available.
Required end result inside the program:
The completed interface must clearly show what the entire discovery process found. A blank page or a simple “completed” message is not acceptable.
The results must include:
* Exact historical period analyzed.
* Total raw BID and ASK observations.
* Total valid Non-Print events derived.
* Total BID and ASK Line Break structures.
* Total events generated by the 100 BID and 100 ASK structural engines.
* Total generated features.
* Total features actually tested.
* Proof that no generated feature was silently excluded.
* Separate long and short testing for every feature.
* Total strategies and combinations evaluated.
* Total strategies meeting the minimum trade requirement.
* Total strategies entering robustness validation.
* Total accepted and rejected strategies.
* Rejection reason for every failed candidate.
* Number of trades for each strategy.
* Net profit and return.
* Win rate.
* Profit factor.
* Maximum drawdown.
* Sharpe ratio or equivalent risk-adjusted measurement.
* In-sample and out-of-sample results.
* Walk-forward results.
* Monte Carlo results.
* Performance after spread, slippage, and trading costs.
* Ranked strategy results.
* Equity curve for each accepted strategy.
* QuantConnect LEAN export for every strategy passing all required gates.
* A machine-readable audit report proving the completeness of the research process.
The current program generates approximately 3,243 features. Every generated feature must be tested. At minimum, each feature must receive both a long and short baseline evaluation before combination searches begin. The interface must show the exact generated and tested counts.
If no strategy passes, the program must still produce a complete visible result explaining why. It must show the closest candidates, their statistics, and the exact gates they failed. Validation standards must not be secretly weakened merely to manufacture a winning strategy.
Final delivery requirements:
* Return one complete patched Windows program.
* Do not provide isolated scripts that I must manually integrate.
* Preserve the existing three-program architecture and current research logic.
* Include a simple installer and launcher.
* Do not include my private OANDA credentials in source code, logs, tests, exports, or the delivered package.
* Test the complete workflow from historical collection through final strategy results.
* Test interruption and resumption.
* Test throttling, timeouts, temporary provider failures, corrupted data, duplicate data, and unavailable periods.
* Keep the GUI responsive throughout the process.
* Provide an acceptance report showing what was implemented, what was tested, and any genuine external limitation that cannot be fixed in code.
The exact program I will supply for modification is:
FOREX_THREE_PROGRAM_SUITE_v8.1.1_90DAY_PROOF_COMPLETE.zip
This supplied ZIP is the clean program package. I will enter my private OANDA credentials locally after receiving the completed version.
Title: Speed Optimization and Completion of Forex Non-Print Quant Research Program
I have an existing Windows-based, three-part quantitative research program designed to discover and validate trading strategies for OANDA forex markets. The program is functional, but its historical tick-data backfill is too slow and produces excessive timeout and service-error messages.
I need an experienced Python, market-data, and quantitative-research developer to optimize and complete the existing program. I am not requesting a rebuild from scratch.
The program uses historical BID and ASK tick data to derive Non-Print events and Line Break market structures. I want it to collect as much legitimate historical data as can reliably be obtained, as quickly as possible, while preserving the exact order and integrity of the data.
I am not requiring a particular historical-data provider. The developer may select or combine appropriate legitimate sources, provided the data is genuine BID/ASK tick or quote data suitable for deriving the existing Non-Print structures. Candle, OHLC, interpolated, fabricated, randomly generated, or synthetic data is not acceptable.
Required backfill improvements:
* Obtain as much usable historical BID/ASK tick data as possible.
* Maximize sustained download speed without overwhelming providers.
* Use asynchronous downloading, connection reuse, intelligent batching, and adaptive concurrency.
* Automatically adjust the worker count based on latency, throttling, and failure rates.
* Process and save completed data immediately instead of waiting for an entire batch.
* Prevent one slow request from blocking every other completed request.
* Checkpoint every completed segment.
* Resume from the exact stopping point after closure, crash, internet loss, or Windows restart.
* Never redownload data that has already been verified and saved.
* Retry temporary failures through an organized repair queue.
* Distinguish genuine market closures or unavailable history from temporary connection failures.
* Validate timestamps, BID prices, ASK prices, sequence order, duplicates, malformed records, and crossed markets.
* Maintain clear provenance if more than one compatible historical source is used.
* Continue accumulating new OANDA forex data after the historical backfill.
* Preserve all existing Non-Print, Line Break, feature-engineering, strategy-discovery, validation, and QuantConnect LEAN functionality.
The program should not display continuous raw timeout, HTTP, connection, or service-error messages to the user. Temporary provider problems should be handled internally through retry logic, backoff, adaptive concurrency, and repair queues.
The visible interface should show simple, understandable status information:
* Running, paused, completed, or repairing.
* Historical date range requested.
* Historical date range successfully collected.
* Completed segments versus remaining segments.
* Total BID/ASK ticks saved.
* Current download speed.
* Current worker count.
* Retry-queue size.
* Data gaps still requiring repair.
* Elapsed time.
* Estimated time remaining.
* Whether enough data is available to begin research.
A genuine unrecoverable problem must produce one concise, actionable explanation. The application must not freeze, silently stop, repeatedly flood the log with the same errors, falsely report completion, or discard downloaded progress.
Fast preliminary result:
I want the application to obtain a useful recent research window first, run the complete strategy-discovery pipeline, and show me a preliminary result without forcing me to wait for the maximum historical archive.
After that preliminary research result is available, the program should be capable of continuing its historical expansion and live-data accumulation without erasing previous work. Research can then be refreshed as more history becomes available.
Required end result inside the program:
The completed interface must clearly show what the entire discovery process found. A blank page or a simple “completed” message is not acceptable.
The results must include:
* Exact historical period analyzed.
* Total raw BID and ASK observations.
* Total valid Non-Print events derived.
* Total BID and ASK Line Break structures.
* Total events generated by the 100 BID and 100 ASK structural engines.
* Total generated features.
* Total features actually tested.
* Proof that no generated feature was silently excluded.
* Separate long and short testing for every feature.
* Total strategies and combinations evaluated.
* Total strategies meeting the minimum trade requirement.
* Total strategies entering robustness validation.
* Total accepted and rejected strategies.
* Rejection reason for every failed candidate.
* Number of trades for each strategy.
* Net profit and return.
* Win rate.
* Profit factor.
* Maximum drawdown.
* Sharpe ratio or equivalent risk-adjusted measurement.
* In-sample and out-of-sample results.
* Walk-forward results.
* Monte Carlo results.
* Performance after spread, slippage, and trading costs.
* Ranked strategy results.
* Equity curve for each accepted strategy.
* QuantConnect LEAN export for every strategy passing all required gates.
* A machine-readable audit report proving the completeness of the research process.
The current program generates approximately 3,243 features. Every generated feature must be tested. At minimum, each feature must receive both a long and short baseline evaluation before combination searches begin. The interface must show the exact generated and tested counts.
If no strategy passes, the program must still produce a complete visible result explaining why. It must show the closest candidates, their statistics, and the exact gates they failed. Validation standards must not be secretly weakened merely to manufacture a winning strategy.
Final delivery requirements:
* Return one complete patched Windows program.
* Do not provide isolated scripts that I must manually integrate.
* Preserve the existing three-program architecture and current research logic.
* Include a simple installer and launcher.
* Do not include my private OANDA credentials in source code, logs, tests, exports, or the delivered package.
* Test the complete workflow from historical collection through final strategy results.
* Test interruption and resumption.
* Test throttling, timeouts, temporary provider failures, corrupted data, duplicate data, and unavailable periods.
* Keep the GUI responsive throughout the process.
* Provide an acceptance report showing what was implemented, what was tested, and any genuine external limitation that cannot be fixed in code.
The exact program I will supply for modification is:
FOREX_THREE_PROGRAM_SUITE_v8.1.1_90DAY_PROOF_COMPLETE.zip
This supplied ZIP is the clean program package. I will enter my private OANDA credentials locally after receiving the completed version.
Apply on Freelancer →
Project sourced from Freelancer.com. Applications happen directly on the original platform — we never collect your data.