Writing an article on "How to write a TOR for a trading robot" - page 6

 
Aleksey Vyazmikin:

This is where a lot of details come out and mistakes are made. That's why it's imperative that the EA is tested on real quotes.

You just need to take this into account, and agree on a reasonable timeframe.


The technical task is a thing, the execution of which can be objectively checked by a third party. Otherwise it is an assignment for a school essay "about summer".


About goodness

 
Maxim Kuznetsov:


A technical task is something that can be objectively verified by a third party. Otherwise, it's a school essay assignment "about summer."

An A for the essay. Great imagination.

But, something you skipped the topic - I'm saying that the test must be based on real data and the customer should be aware of this, and the contractor should take it into account in the declared deadlines.

 
Aleksey Vyazmikin:

5 for the essay - great imagination!

But, you've jumped the subject - I'm saying that testing is mandatory on real data and the customer should be aware of this, and the contractor should take it into account in the stated deadlines.

Suppose you have written an EA (code and for the most part debugged even). The next objective thing - to check the owl on the real account for the client, you need some time and the same real account.

How do you all together make sure that the task is done?

 
Maxim Kuznetsov:

Suppose you have written an EA (code and for the most part debugged it even). Then an objective thing follows - to check the owl on a real account the customer, you, the arbitrator need some time and the same real account.

How will all of you check if the task is fulfilled?

If you are not sure of the correctness of the order, you may use the terminal's service logs and check the order processing logic.

What is the problem? Yes, I actually encountered a working EA in the tester that wasn't working properly on a real account, yes the EA claimed it should be, the arbitrator kept silent until I pulled out a piece of code and poked the EA's nose in it. Wasted a lot of my time and nerves on the Contractor's incompetence, so I see no problem if the Contractor waits for his remuneration.

Or maybe I don't understand something, please elaborate on your arguments for a substantive discussion.

 
Maxim Kuznetsov:

What is all this for?

The requirements specification is written by the contractor (or a specially trained third party consultant). And it includes the methodology of verification.
Any unnecessary requirements for the customer, he is not obliged to be aware of all programming.

The customer should say (in writing, not video or Skype):

- I use these indicators and scripts

- I stick to the following rules

- Have traded on more or less official demo for one week, month or year, this is how much. And in another period like this. All optionally backed up by copying to a cent account.

- you need to automate

The Developer prepares and agrees upon TT (in a form understandable to both parties), writes an owl, and if everything in the tester more or less converges with the mentioned period, then the Expert Advisor is done.

Variants - we should check it on the demo/center-real/etc., it's already beyond the limits of freelancing

I'm not involved in freelancing for many reasons, but writing the TOR costs money and often a lot. And, as I see it, the average check in freelancing is $50. B what, from this already miserable sum still to scratch out to pay the Contractor for writing TOR? Or he will write for free?

 

I added a little more to the article - I added the section What should be in the Terms of Reference and wrote Where to get the Terms of Reference if you cannot compose it yourself

Что нужно для заказа торгового робота

Trading robots are programs that execute the algorithms embedded in them. Algorithms are a set of actions that must be performed in the event of the occurrence of an event. For example, the most common task in algorithmic trading is the definition of the "New bar" event , upon the appearance of which the robot checks for the appearance of trading signals and performs the necessary actions on them.

But before writing or ordering a trading robot, it is necessary to have a trading system with clear rules for determining favorable moments for making transactions. The development of any, even the most complex, trading system always starts with basic things, namely, with the development of trading signals for buying and selling. Next, you can add various follow-up and closing options to it.

You do not need to spend years behind the monitor of the trading terminal to develop your trading strategy. There are now hundreds of proven ideas published on the Internet and in books that you can try. And even if you are not completely confident in your programming skills, this is not an obstacle. The Freelance service will help you find the right developer and securely pay for the work done.

But before jumping into the fascinating element of algorithmic trading, we recommend that you read useful articles on the topic:

Why is it important to have a good Terms of Reference?

When ordering or developing an Expert Advisor, it is necessary to formulate technical requirements for it - what tasks it should solve, in what conditions it will be operated, what will happen in emergency situations, what kind of control it needs. Trading robots are programs and must work clearly in accordance with the underlying logic. But before programming the necessary algorithm of actions, it must also be clearly described.

The description of the trading strategy must be issued in the form of a Terms of Reference. And the better and clearer it will be, the less misunderstanding will be between you, as a customer, and the programmer, as the executor of your Order.

The most important thing in the Terms of Reference is the presence of formal unambiguous Trading Rules. Even if you are not going to order an expert on the side, but want to write it yourself, start by developing these rules for yourself. Make a Terms of Reference and be sure to include items on testing/optimizing the Expert Advisor. Also add hypotheses to test the quality of your trading strategy - what criteria will you use to select the optimal parameters, why do you consider these criteria important.

Include all the steps for creating a trading robot in the Terms of Reference - this will help to understand the essence of the algorithm not only for the performer, but also for you after weeks, months or years. Remember, algorithmic trading is not a hobby, but the same monotonous research path, during which it is necessary to document the stages passed. For myself, more than for a programmer who will write a robot for you.

Develop the skills of a bureaucrat who likes to sort things out. You will definitely need this. Yes, and programmers love clear-cut orders.

What should be in the terms of reference

trade idea

For a quick introduction to the essence of a trading strategy, dedicate the first paragraph of your Technical Order to the idea / hypothesis that it contains. For example: "If the price approaches the resistance level twice and rolls back each time, then the third time, as a rule, it breaks through it." Here you can attach a chart with plotted resistance/support lines, superimposed indicators and signatures that illustrate the situation. To describe the idea, it is not required to give specific numbers or calculation algorithms - at this stage, it is not required to explain how we determine:

  • resistance level,
  • level breakdown,
  • the concept of "generally".

A small level of abstraction at the initial stage will allow you to focus on the idea itself, and not on the technical details. This method allows you to subsequently generate many more varieties of your trading strategy - you will simply replace one strategy block with another, one indicator with another, add or replace filters. At the same time, the idea itself will not change, only the names and values of the input parameters of your trading robot will change.

Further, it is necessary to give a description of all the terms that are used in the description of the idea. If the trend is important for the strategy, give a clear description of how it will be determined - on the basis of which indicator, how the direction and strength of the trend will be determined. The numerical characteristics of these definitions will form the basis of the input parameters of the Expert Advisor, and it is them that you will then optimize in the strategy tester. So name the first section of your Terms of Reference - Trade idea.

Terms

To describe the terms, we recommend creating a separate section of the Terms of Reference - Terms. In it, a separate paragraph is written for each term, the terms themselves are written in bold to highlight the key concept of your trading strategy. If necessary, add an illustration to the description of the term, in which you need to show the most necessary for understanding.

Trading Signals

Next, you are ready to compile the third most important section - Trading Signals - which describes under what conditions, market conditions, and indicator readings, a purchase occurs. To describe each condition necessary to generate a buy signal, it is necessary to single out a numerical parameter, on which the appearance of the signal depends. For example, for a moving average , this would be the smoothing type and period. These important parameters are taken into the input parameters of the future Expert Advisor. Describe separately the conditions for the sale, even if they are simply the opposite of the conditions for the purchase - sometimes subtleties come out that the programmer can understand differently from you. For example, for a purchase, the condition "Indicator> 0" is set - what to write for a sale? "Score<0" or "Score<=0"?

Even the simplest trading idea very quickly begins to acquire additional conditions and filters that confirm the presence of a trading signal or vice versa - prohibit a deal. Therefore, it is important to make explanatory screenshots for each market situation, which visually show the necessary indicators and setups. This will allow you to quickly deal with the situation when your adviser missed a seemingly obvious trading signal or suddenly made a deal at the wrong time.

Screenshots and flowcharts

There are a lot of free and handy programs on the Internet for creating screenshots and flowcharts. A small selection of tips for working with them is given in the article How to draw up a Terms of Reference when ordering an indicator . There you will also find tips on ordering an indicator that shows with arrows on the chart the moments when buy and sell signals appear. Such an indicator, which works separately from the adviser, makes it easier to check and control the operation of the trading robot both online and during visual testing.

Lifetime of signals/orders/positions

The second important part of the trading strategy is exiting an open position and deleting pending orders. In addition, the trading signals themselves can also be canceled by time or by the occurrence of some events. It is also necessary to clearly describe, as for Trading signals, under what conditions the purchase / sale will be closed, the placed order will be canceled, when the signal itself will be canceled.

Maintenance of open positions and pending orders

If your trading strategy requires setting StopLoss and TakeProfit levels, please provide a calculation algorithm. If it is necessary to flexibly pull up/move these levels, it is also necessary to describe the conditions for such operations. SL/TP levels can be modified both at the opening of a new bar and at each tick. It is necessary to explicitly indicate this moment in the Terms of Reference and understand the difference in the modes of testing trading strategies. We recommend that you read the article Testing trading strategies on real ticks .

Where can I get the Terms of Reference if you can’t compose it yourself

A poorly drawn up Terms of Reference or its actual absence most often indicates that the rules of the trading system are not formulated, they simply do not exist. What in this case the Customer calls a trading system, in fact, as a rule, is just an idea. It is impossible to start work under such conditions, because very soon unaccounted for nuances or simply the absence of an algorithm in certain market situations will come out in the process of programming the algorithm. In this case, the programmer actually begins to come up with options instead of the Customer.

As a result, the Contractor may, at his own peril and risk, complete the work and issue a trading robot to the Customer. But in this case, in addition to wasting time discussing each new issue in an unclear TOR, there is also the possibility of the work getting into Arbitration. Because when accepting and checking such work, the Customer suddenly discovers that transactions are not being made as he expected, but could not describe. And of course, in this case, he will blame the Contractor for violating certain points of the Terms of Reference and incorrectly programming the robot. Arbitration in such cases quickly understands the difference in the competence of both parties and makes its decision based on the Terms of Reference attached to the order. According to the Freelance Rules , no correspondence on the side before and during the execution of the Order is not taken into account:

When considering the subject of the dispute in the Arbitration, only the Terms of Reference serve as the basis for making a decision.

In life, this option is also possible: you have strict trading rules, but for some reason you cannot draw up the Terms of Reference yourself. For example, they are not sure how to describe certain things correctly or they need the help of a specialist in mathematics, neural networks, machine learning, programming, and so on. In this case, you can order the creation of the Terms of Reference also in Freelance, for this, the categories "Programming Consulting" or "Other" are suitable.

Choose one of these two categories, name it "Creating a TOR for ordering a trading robot" and indicate the initial cost of the work, as you imagine. An experienced trading system developer will help you correctly formulate the Rules of your strategy so that they are understandable to another programmer. At the same time, you should be able to work with charts, indicators, and graphical objects in order to show the setups of your trading signals using screenshots.

The programmer will understand your trading system and help you write a description of the trading algorithm, if possible. If you can't formulate some concepts on your own (for example, "impulse" or "rebound from the level"), he can give you ready-made ideas based on his experience. As a rule, any situation in the market can be described logically (and then programmatically) with some freedom of interpretation. And this variation can always be expressed by a certain parameter, which you will then optimize in your Expert Advisor.

There are no ideal patterns, since the market, on the one hand, does not repeat itself, and on the other hand, similar situations can always be found in history. The result of your joint work should be a ready Terms of Reference for ordering a trading robot according to your strategy.

What terms to use

... it is better to describe terms that are not sure in order to understand each other

In the TK itself, highlight the terms in bold - let the performer pay attention to them and ask a question if something is not clear

You can not send to other sources (websites / books, etc.) Everything should be described here and now, no "I'll explain later on Skype"

What to write in a job description in Freelance

... only a general formulation is needed - trend, counter-trade. to break through levels (how levels are defined in short), are there any indicators/Price Action/use of ticks

General idea of a trading strategy

... we trade according to the trend, we define the trend in this way, we enter on a rollback, we define a rollback in such and such a way, we do not trade in the evening and in the morning

Description of the setup for waiting for a Signal

... it is necessary to form a flat with a subsequent breakout / or wait for the end of the European session and receive signals only in the direction of its movement

Signal Description

... Technical parameters of the description - trend / pullback / breakdown - everything is strictly formalized

It is better to debug Buy and Sell signals separately first

It would be better if the adviser puts labels / signal objects on the chart

It is better if signal indicators are made separately

Signal lifetime

... how long the signal is valid - in bars / hours / until the end of the session / day

Placing orders and opening positions

... are there any features, for example, we don’t set SL / TP right away,

or how many attempts we make to enter the market,

or setting different oredermagic/ordercomment depending on time/setup/pattern

something else

Maintenance of a trading position/order

... is there a trailing stop or not

when turn on TS

do we move pending orders behind/against the price

track the current profit/loss on an open position

something else

Cancellation of an order and closing a position

... delete orders by time/number of bars/end of period/appearance of opposite signal/loss of setup

... close the position by time/number of bars/end of the period/accumulated profit/appearance of the opposite signal/setup

something else

Lot calculation for placing an order

.... from balance

fixed

from accumulated profit

based on the results of the last N trades

from risk (distance SL)

something else

Handling trading errors and environment state

... detailed logs when sending trade orders

terminal/connect/server restart processing

feedback via messengers/email

The difference between trading at the opening of the bar and inside the bar

... signals can disappear and appear during the life of the bar

Tick/scalping strategies

... you need to have a good idea of what it is, the less TakeProfit/StopLoss in points, the more critical the strategy is to spreads/commissions/network delays/quality of available history/speed of the robot itself.

Any deterioration in conditions can kill the strategy

Grids, martingales, averaging and the downside of these improvements

... What are they, why are they popular, and how much can they help temporarily stretch the strategy. The risk increases, although it may lengthen the life of a bad strategy

What to look for when choosing a contractor

... substantive questions

Doesn't pretend to impress

Gives clear deadlines

Indicates unclear places in the TOR immediately, and not after 2 months of discussion

A good programmer values his and your time - that's why he loves a well-developed consistent TOR

What a programmer can't do for you

Turn a losing strategy into a profitable robot

Optimize and identify any shortcomings

Write a program without errors - they will still be. Finding them and describing them in an understandable way is your task.


 
Rashid Umarov:

...

Screenshots and flowcharts

There are plenty of free, handy programs on the internet for creating screenshots and flowcharts. ...

Flowcharts are the most useless, time-consuming and practically unrealizable part of ToR.

To understand this - you can make a small and very simple experiment - Freelance service developers should be given a task: "Make a flowchart for drawing MA indicator" - and then evaluate by two criteria: 1) correctness and 2) understandability.

 
Andrey F. Zelinsky:

Flowcharting is the most useless and practically unrealizable part of ToR.

To understand this - you can make a small and very simple experiment - Freelance service developers should be given a task: "Make a flowchart for drawing MA indicator" - and then evaluate by two criteria: 1) correctness and 2) readability.

Here we are talking not about a flowchart of calculation algorithm, but a flowchart of the sequence of actions and relationships between different blocks of the program - decision-making, position management, filters, etc.

 
Aleksey Vyazmikin:

This is not a block diagram of a calculation algorithm, but rather a flowchart of the sequence of actions and relationships between different program blocks - decision-making, position management, filters, etc.

Can you imagine the level of a customer who, at least perfectly understanding the client terminal's events, will be able to describe "sequences of actions and relationships of different program blocks - decision making, position management, filters, and so on" qualitatively?

And then check it all from the point of view of program implementation - otherwise why make a flowchart?

Such a customer won't be able to see the developer's name not only before the agreement, but also after it's done (if it will ever happen with such an entry level customer) -- "whoever multiplies knowledge multiplies sorrow" (Ecclesiastes 1:17-18)


p.s. Again. To check my thesis about the practical uselessness of making a flowchart (any) is very simple.

It's enough to set a task to Freelance service developers - to write a flowchart for MA indicator.

Thesis № 2 - no more than 5-10% will do the job.


p.s.2 Question 1 - in computer science class (at school or university) who (what percentage) thought that making a flowchart was useful?

Question 2 -- who (what percentage) made a flowchart more complicated than, for example, "search for the maximum element in an N-dimensional array" during their practical work.

 
Andrey F. Zelinsky:

Can you imagine the level of the customer who, at the very least, perfectly understands the events of the client terminal, will be able to describe "sequences of actions and relationships of different program blocks - decision-making, position management, filters, and so on" in a qualified way?

And then check it all from the point of view of program implementation - otherwise why make a flowchart?

Such a customer won't be able to see the developer's name not only before the agreement, but also after it is done (if it ever happens with this level of customer) -- "whoever multiplies knowledge multiplies sorrow" (Ecclesiastes 1:17-18)

A block diagram is useful, at least to test your logic. Yes, I do flowcharting as a concept or when I am developing a complicated algorithm, most often on paper.

An EA is not a finished product, it will always be subject to revision, as long as the customer is interested in its idea, so this customer had better take care of possible revisions, and for this code must have a certain structure. I once understood this after probably 5 freelance EAs were ordered. The high level of idiocy is when the logic of making trading decisions is packed into trading functions - no wonder that such an EA is not subject to revision, but has to be reworked, especially if the Developer is another person.

Reason: