Een handelsidee kan heel duidelijk lijken wanneer je naar een grafiek kijkt. Je weet welke situatie je zoekt, wanneer je zou instappen en welke trade je liever overslaat. Zodra je het aan een ontwikkelaar uitlegt, veranderen een paar kleine vragen het gesprek: welke candle telt, mag het systeem opnieuw instappen en wat als een andere strategie dezelfde rekening al gebruikt?
Bij die vragen begint een groot deel van het echte werk. Bij POLARIS zien we de ontwikkeling van handelssystemen als een manier om je idee helder genoeg te maken om het te bouwen, te testen en met vertrouwen te gebruiken. Goede code is belangrijk. Even belangrijk is dat die code het idee volgt dat jij werkelijk voor ogen hebt.
Ons gepubliceerde archief bevat 170 registraties: 169 ontwikkelregistraties en één intern onderzoek. Het gaat om nieuwe systemen, aanpassingen aan bestaande tools, integraties en herstelwerk. Die verscheidenheid vormt de achtergrond van de lessen hieronder. De drie voorbeelden zijn voor dit artikel gemaakt; ze verduidelijken de redenering zonder klantprojecten bloot te leggen.
1. Een kleine vraag kan elke trade veranderen
Stel dat je een systeem vraagt dat koopt zodra een indicator positief wordt. Dat klinkt als een volledige instructie. Maar bedoel je “koop één keer wanneer de waarde boven nul kruist” of “koop telkens wanneer de waarde boven nul staat”?
Vijf metingen maken het verschil duidelijk. We nemen aan dat geen andere regel een instap blokkeert. Elke rij is een nieuwe controle van de indicator; vóór de eerste meting stond de waarde op −0,2.
| Meting | Indicatorwaarde | Koop bij elke positieve waarde | Koop alleen bij een kruising |
|---|---|---|---|
| 1 | 0,3 | Koopverzoek | Koopverzoek |
| 2 | 0,4 | Koopverzoek | Geen nieuwe koop |
| 3 | 0,1 | Koopverzoek | Geen nieuwe koop |
| 4 | −0,1 | Geen nieuwe koop | Geen nieuwe koop |
| 5 | 0,2 | Koopverzoek | Koopverzoek |
De regel die alleen naar een positieve waarde kijkt, levert vier koopverzoeken op. De kruisingsregel levert twee nieuwe signalen op. Geen van beide is vanzelf juist: misschien wil je juist herhaaldelijk instappen. Het probleem ontstaat wanneer die keuze wordt overgelaten aan degene die de code schrijft.
Stel nu dat de eerste trade sluit terwijl de indicator nog positief is. Moet het systeem opnieuw instappen? De instelling “één trade tegelijk” beantwoordt die vraag niet. Ze kan de onduidelijkheid verbergen tot de eerste positie sluit.
Wat we vóór de bouw zouden afspreken: in dit voorbeeld controleren we gesloten candles. Er ontstaat alleen een signaal als de vorige waarde nul of lager was en de nieuwe waarde hoger dan nul is. Elk signaal krijgt een unieke referentie, zodat dezelfde candle na een herstart geen tweede order kan veroorzaken. Als handelen niet wordt toegestaan, vervalt het signaal bij de volgende candle. Ontbrekende indicatorgegevens betekenen geen instap.
Zo controleer je het: speel de vijf metingen opnieuw af en verwacht twee signaalreferenties. Herhaal de eerste meting en herstart het systeem: geen van beide mag nog een order voor hetzelfde signaal opleveren. Dit zijn verwachte uitkomsten volgens onze voorbeeldregels, geen gemelde resultaten van een klanttest. Handelen binnen een candle kan ook, maar vraagt andere, even duidelijke afspraken.
2. Twee passende trades kunnen samen te groot zijn
Risico-instellingen kunnen geruststellend lijken als je elke strategie afzonderlijk bekijkt. De moeilijkere vraag is wat er gebeurt wanneer meerdere strategieën tegelijk willen handelen.
Neem een rekening van $10.000. In dit voorbeeld mag elke trade bij de stop maximaal $100 riskeren, terwijl het totale geplande verlies op de rekening binnen $150 moet blijven. Twee systemen vragen elk een trade met $90 gepland risico aan. Beide blijven binnen hun eigen limiet. Samen hebben ze $180 nodig.
Het tijdstip van de controle telt mee. Als beide systemen de rekening bekijken voordat een van de trades zichtbaar is, kunnen ze allebei denken dat de volledige $150 nog beschikbaar is. De procentberekening kan dus kloppen terwijl de beslissing voor de rekening als geheel fout gaat.
Een gezamenlijke risicocontrole lost dit voorbeeld op door meteen $90 te reserveren voor het eerste aanvaarde verzoek. Er blijft $60 over, dus het tweede verzoek van $90 wordt geweigerd. Hier houden we de positiegrootte vast; de tweede trade verkleinen zou een aparte afspraak zijn.
Die reservering mag niet zomaar verdwijnen omdat een antwoord uitblijft. Bevestigt de broker de afwijzing, dan kan het bedrag worden vrijgegeven. Is de uitkomst onbekend, dan moet het systeem eerst de werkelijke orders en posities controleren. MetaQuotes legt uit waarom één handelsverzoek meerdere afzonderlijke updates kan opleveren.
Zo controleer je het: stuur beide verzoeken tegelijk, vertraag één antwoord en herhaal de test na een herstart. Het gebruikte plus gereserveerde geplande risico mag nooit boven $150 komen. Dat is een ontwerplimiet, geen garantie dat het verlies daar stopt: koerssprongen, slippage en mislukte uitstappen kunnen een groter verlies veroorzaken.
3. Achteraf kan een grafiek duidelijker lijken dan ze toen was
Er verschijnt om 10:05 een signaal op de vijfminutengrafiek. Je wilt bevestiging van de uurtrend. Welke uurcandle moet het systeem lezen?
Om 10:05 is de vijfminutencandle van 10:00 tot 10:05 gesloten. De uurcandle van 10:00 tot 11:00 heeft nog 55 minuten te gaan. De eindwaarde ervan is nog onbekend. Gebruikt de regel gesloten candles, dan is de beschikbare uurcandle die van 09:00 tot 10:00.
Op een afgewerkte grafiek vergeet je dat verschil gemakkelijk. Een vergelijking die de eindwaarde van 11:00 gebruikt voor een beslissing om 10:05, geeft het systeem informatie die het toen niet kon hebben. Je kunt ook bewust de nog veranderende uurcandle gebruiken, maar dat is een andere regel die op die manier getest moet worden.
Wat we zouden afspreken: uit welke candle elke waarde komt, wanneer ze bruikbaar wordt en wat er gebeurt bij late data. In dit voorbeeld betekent ontbrekende koershistoriek wachten of overslaan volgens de afspraak, nooit ongemerkt een onvoltooide candle gebruiken.
Zo controleer je het: bij de beslissing om 10:05 moet het logboek de uurcandle noemen die om 10:00 eindigt en de vijfminutencandle die om 10:05 eindigt. Vertraag één van de invoeren en controleer het afgesproken wacht- of overslaggedrag. Deze tijden veronderstellen doorlopende data en één vastgelegde servertijdzone; rond marktsluitingen moeten de werkelijke tijdstempels worden nagekeken.
4. Correcte software en een bruikbare strategie vragen andere controles
De voorbeelden vragen of de software doet wat is afgesproken. Een systeem kan al die controles doorstaan en toch geld verliezen. Daarom hoort ook de beoordeling van het handelsidee bij een goed gesprek over de oplevering.
Een backtest toont hoe regels zich op historische prijzen gedroegen onder de gekozen testomstandigheden. Dat is nuttig, maar de uitkomst hangt ook af van kosten, datakwaliteit en de simulatie van trades. Verdwijnt het schijnbare voordeel bij een kleine stijging van de spread, dan wil je dat weten voordat je op het systeem vertrouwt.
Een praktische aanpak is het idee op één periode te ontwikkelen en daarna op een afzonderlijke periode te testen die bij die beslissingen niet werd gebruikt. Vervolgens observeer je het systeem vooruit in de tijd, onder vastgelegde omstandigheden. Gebruik je de aparte periode steeds opnieuw om de strategie bij te stellen, dan is ze geen verse controle meer. Elke stap voegt informatie toe; geen ervan garandeert de volgende.
Ontwikkelaar en klant moeten afspreken wat slagen voor elke test betekent. “Het systeem opende precies de twee bedoelde trades” is een software-uitkomst. “De strategie bleef na kosten bruikbaar op ongeziene data” vraagt afzonderlijk handelsbewijs.
5. Je moet kunnen begrijpen wat je systeem doet
Een systeem moet ook na de eerste geslaagde test bruikbaar blijven. Als het niet handelt, wil je kunnen zien of er geen signaal was, de risicolimiet bereikt was of koersdata ontbraken.
Een melding als “trade mislukt” laat te veel open. “Instap overgeslagen: $60 beschikbaar, $90 nodig” zegt wat er gebeurde en waar je moet kijken. De softwareversie, het beslismoment en het antwoord van de broker helpen om een gewijzigde regel te onderscheiden van gewijzigde handelsomstandigheden.
Een herstart verdient dezelfde aandacht. Herkent het systeem een bestaande positie? Kan het een eerder verzonden order herhalen? Een nuttige oplevering omvat heldere instellingen, een korte handleiding en controles voor zulke situaties. Dit zijn opleverpraktijken die we aanbevelen; het archief bewijst niet dat elke historische registratie ze bevatte.
Wat betekent dit voor jouw project?
De waarde van ervaring zit in het tijdig stellen van de juiste vragen, wanneer antwoorden nog gemakkelijk aangepast kunnen worden. Een nieuwe strategie, de omzetting van een indicator en een reparatie vragen geen identiek plan. Ze vragen wel hetzelfde gedeelde begrip van wat het eindresultaat moet doen.
Voor een eerste gesprek met POLARIS zijn drie dingen bijzonder nuttig: een voorbeeld van een gewenste trade, een voorbeeld dat je wilt vermijden en de grenzen die het systeem moet respecteren. Je hoeft geen technische specificatie mee te brengen. Die voorbeelden geven ons een concreet vertrekpunt om er samen één te maken.
- Vóór ontwikkeling: spreek signalen, timing, positielimieten en gedrag bij ontbrekende informatie af.
- Vóór aanvaarding: doorloop een normale situatie, een grensgeval en een foutscenario, met de verwachte uitkomst op papier.
- Vóór je erop vertrouwt: bekijk het handelsbewijs, de gebruiksinstructies en het herstel na storingen.
Ons doel is dat je jouw eigen handelsidee herkent in het afgewerkte systeem en begrijpt hoe het gedrag is gecontroleerd. Zorgvuldige ontwikkeling kan dat vertrouwen verdienen.
Bespreek je handelsidee met POLARIS · Bekijk onze ontwikkelcapaciteiten
Het archief van dichterbij
Het archief laat zien hoe uiteenlopend het werk achter dit gesprek is. Het meet geen winstgevendheid en vertelt niet hoe vaak een bepaalde fout voorkwam. Hieronder kun je de aantallen controleren zonder de praktische lessen te onderbreken.
Wat de 170 registraties omvatten en hoe je de cijfers leest
De cijfers komen uit de gepubliceerde archiefdata. Eén rij is één geregistreerd werkitem, niet noodzakelijk één afzonderlijke klant of strategie.
| Soort werk | Registraties |
|---|---|
| Nieuwe ontwikkeling | 117 |
| Aanpassing en uitbreiding | 34 |
| Conversie en integratie | 12 |
| Foutopsporing en herstel | 6 |
| Intern onderzoek | 1 |
De 169 ontwikkelregistraties zijn gedateerd van november 2020 tot februari 2024. Bij het interne onderzoek ontbreken een gepubliceerde datum en duur. Dit is een momentopname van het archief, geen actuele totaaltelling van al het POLARIS-werk. De data bevatten geen goedkeuringsverslagen van klanten, rekeningrendementen of gemeenschappelijke acceptatiechecklist.
Platformen: de labels tellen op tot 81 MT5-, 71 MT4- en 18 gecombineerde MT4/MT5-registraties. Daarvan zijn er 108 uitdrukkelijk als afgeleid gemarkeerd: 52 MT5 en 56 MT4. De overige 62 zijn 29 MT5, 15 MT4 en 18 gecombineerd; “niet als afgeleid gemarkeerd” betekent nog geen onafhankelijke verificatie. De afgeleide MT4-datums lopen van november 2020 tot december 2021, die voor MT5 van januari 2022 tot januari 2024. Ze mogen niet als bevestigde platformervaring worden voorgesteld.
Categorieën: elke rij heeft één hoofdonderwerp en kan meerdere kenmerklabels hebben. Rij 1 heeft bijvoorbeeld risico- en tradebeheer als hoofdonderwerp, met labels voor positiegrootte en stopbeheer. Het blijft één registratie. Een ontbrekend label betekent “hier niet vastgelegd”, niet noodzakelijk “niet gebouwd”. Onbekende datums en looptijden blijven onbekend.
De exacte kenmerktellingen omvatten 45 registraties voor positiegrootte, 7 voor meerdere tijdframes en 6 voor indicatorintegratie. Daarnaast zijn 6 rijen specifiek als herstelwerk ingedeeld. Deze cijfers beschrijven het archief; het zijn geen foutentellingen en ze bewijzen niet dat de beveiligingen uit de voorbeelden telkens zijn opgeleverd.
Sommige oudere pagina's gebruiken bredere themagroepen. De tabel houdt die gepubliceerde samenvattingen apart van aantallen die rechtstreeks uit de rijen kunnen worden nageteld.
| Onderwerp | Oud hubtotaal | Artikelselectie | Telling uit de data |
|---|---|---|---|
| Indicatorintegratie | 11 | 10 | 6 — kenmerklabel |
| Grid en hedging | 38 | 33 | 33 — hoofdonderwerp |
| Prijsactie en structuur | 26 | 22 | 22 — hoofdonderwerp |
| Data, statistiek en machine learning | 9 | 3 | 3 — hoofdonderwerp |
| Dashboards en scanners | 22 | 14 | 11 — kenmerklabel |
De lijsten die oudere themagroepen en artikelselecties aan afzonderlijke rijen koppelen zijn niet openbaar. Daardoor kunnen de verschillen niet volledig worden verklaard. Tel voor een reproductie elk hoofdonderwerp één keer per rij, of de aanwezigheid van het genoemde kenmerk één keer per rij. Verschillende kenmerken kunnen overlappen.
Het archief weerspiegelt vastgelegd werk en klantvraag, geen representatieve steekproef van de handelssector. Het bevat geen overzicht van stopgezette opdrachten, foutfrequenties of overeenstemming tussen onafhankelijke beoordelaars. Sterkere claims vragen die gegevens. Toekomstige registraties worden beter controleerbaar met de aanvaarde versie, checklist, beslisdatum, beoordelaar en vindplaats van het bewijs.
| Les | Archieftelling | Wat de les verduidelijkt | Wanneer de regel kan verschillen |
|---|---|---|---|
| Definieer het instapmoment | 6 labels voor indicatorintegratie | Voorbeeld 1 toont vier verzoeken tegenover twee signalen; het aantal meet geen fouten. | Herhaald instappen kan de bedoeling zijn. |
| Stem rekeningrisico af | 45 labels voor positiegrootte | Voorbeeld 2 vraagt $180 bij $150 beschikbare ruimte; het aantal bewijst geen gezamenlijke risicocontrole. | Afzonderlijke, geïsoleerde rekeningen delen die ruimte niet. |
| Spreek de juiste candle af | 7 labels voor meerdere tijdframes | Voorbeeld 3 scheidt beschikbare informatie van een latere eindwaarde; dit is geen foutenpercentage. | Een onvoltooide candle gebruiken kan als het is afgesproken en getest. |
| Maak problemen begrijpelijk | 6 herstelregistraties | Het logboekvoorbeeld toont hoe een bruikbare melding helpt; herstelregistraties tellen niet alle defecten. | Herstel kan ook deel uitmaken van nieuwe ontwikkeling of aanpassing. |
Vragen die je misschien nog hebt
Betekenen 170 registraties ook 170 winstgevende klantsystemen?
Nee. Het archief bevat 169 ontwikkelregistraties en één intern onderzoek. Het omvat verschillende soorten werk en stelt het aantal afzonderlijke klanten of winstgevende strategieën niet vast.
Komen de voorbeelden uit individuele klantprojecten?
Nee. We hebben ze gemaakt om de technische keuzes begrijpelijk te maken. Het archief biedt context, maar de voorbeelden zijn geen klantcases of gemeten klantresultaten.
Heb ik een technische specificatie nodig voordat ik POLARIS contacteer?
Nee. Begin met het gewenste handelsgedrag, een voorbeeld dat je zou afwijzen en je operationele grenzen. Die informatie kan het vertrekpunt zijn voor een afgesproken specificatie.
Kan ik de archiefcijfers zelf controleren?
Ja. Met de gekoppelde dataset kun je werksoorten, hoofdonderwerpen en exacte kenmerklabels tellen. Sommige bredere totalen op oudere pagina’s zijn niet volledig te reproduceren omdat hun lijsten met opgenomen registraties niet openbaar zijn.
Herschreven op 6 september 2026. De cijfers verwijzen naar de gepubliceerde momentopname met 170 registraties. Klantidentiteiten, privéspecificaties en code worden niet gedeeld.
