Uit ons onderzoeksnotitieboek

Nieuws-, tijd- en sessiefilters: kleine regels, grote gevolgen

We laten zien hoe eenvoudige nieuws- en sessieverzoeken vragen over klokken, grenzen en bestaande posities opriepen.

“Niet rond nieuws handelen” leek vaak een kleine toevoeging. Het uitwerken daarvan maakte duidelijk hoeveel keuzes erin zitten, te beginnen met de gebruikte klok.

We kiezen een tijdbasis

Brokertijd kan verschuiven en zomertijd begint niet overal tegelijk. We leggen conversies naar sessies en kalendergebeurtenissen vast, zodat dezelfde instelling dezelfde betekenis houdt.

We bepalen de bevoegdheid van het filter

Een entry blokkeren verschilt van een positie sluiten. We beschrijven start en einde, nachtsessies en late ticks. Nieuws vraagt ook regels voor relevantie, revisies en ontbrekende kalenderdata.

We bekijken de uitgesloten kansen

We vergelijken gedrag met en zonder filter op dezelfde waarnemingen en onderzoeken verwijderde trades, klokwissels en datagaten. Zo bespreken we het effect in plaats van het aantal schakelaars.

Bekijk de technische uitwerkingOpen de volledige methode, uitgewerkte voorbeelden en implementatievragen. We bewaren die verdieping hier, zodat je de redenering zo ver kunt volgen als je wilt.

“Trade niet rond nieuws” en “trade alleen in deze sessie” klinken als kleine toevoegingen. In software opent elke zin een keten beslissingen: welke klok, welke eventprioriteit, wat gebeurt op de grens en worden bestaande posities anders behandeld dan nieuwe entries?

Deze filters kunnen de tradesample, de marktregimes die een strategie ziet en het gedrag per broker veranderen. Hun waarde komt dus van precisie en testing, niet van nog een geruststellende aan/uitknop.

Engineeringnota · ENG-10

Een filter is een permissieservice

De instapmodule ontvangt een beslissing, geen verzameling dubbelzinnige klokken.

  1. 01
    NormaliserenZet server-, UTC-, lokale, sessie- en eventtijd om met zomertijdregels.
  2. 02
    ClassificerenBepaal sessiestatus, eventprioriteit, blackoutvenster en dataversheid.
  3. 03
    ToestaanGeef allow, block-new-entry of een gedocumenteerde foutstatus terug.
  4. 04
    RegistrerenLog brontijd, regel, grens en effect op de strategiebeslissing.

Eén tijdlijn

Brokerservertijd is geen permanente tijdzone. Sommige brokers verschuiven seizoensmatig en regio’s veranderen zomertijd op andere datums. De filter heeft één interne tijdsbasis en expliciete omzetting nodig voor sessies, gebruikersinput en kalenderdata.

Definieer de grens

Een venster vraagt inclusieve of exclusieve start en einde, weekdagen, weekendgaps, nachtsessies en gedrag voor de eerste tick na de grens. Nieuwsfilters vragen ook eventniveau, valuta, voor/na-duur, revisies, duplicaten en een beleid voor onbeschikbare kalenderdata.

Scheid entries van posities

Een nieuw signaal blokkeren is iets anders dan een open positie sluiten of wijzigen. Zonder expliciet mandaat mag een operationele filter de originele exitlogica niet stil vervangen. Bij onzekere kalenderdata hoort een gedocumenteerd beleid, geen verzonnen status.

Meet het effect

Een filter wijzigt welke trades in de sample blijven. Test basis en gefilterde versie op dezelfde data, inspecteer verwijderde trades en neem klokwijzigingen en datastoringen op. Een mooiere curve met heel weinig trades kan selectie zijn in plaats van robuustheid.

  • Gebruik één interne tijdzone met expliciete omzettingen.
  • Behandel sessie- en nieuwsgrenzen als testcases.
  • Definieer beleid voor onbeschikbare kalenderdata.
  • Scheid entrypermissie van exitbevoegdheid.
  • Rapporteer hoeveel trades elke filter verwijdert.

Vragen die je misschien hebt

Moet een EA posities sluiten vóór gepland nieuws?

Alleen als dat deel is van de verklaarde strategie of het risicomandaat. Een nieuwsfilter die enkel entries beheert, mag niet stil een exitsysteem worden.

Is brokertijd hetzelfde als lokale markttijd?

Nee. De serveroffset kan verschillen en seizoensmatig veranderen, dus sessieregels vragen expliciete omzetting en testing.

Maak tijd tot een testbare toestemmingsregel

Schuif het diagram horizontaal of open het op volledige grootte.

Maak tijd tot een testbare toestemmingsregel
Educatief ontwerpvoorbeeld — waarden en toestanden zijn geen liveprestaties.

Voorbeeldklok: server UTC+2. Venster: [14:25, 14:35).

Open posities volgen een afzonderlijke beheerregel.

Volledig diagram openen ↗

Maak tijd tot een testbare toestemmingsregel

Stel dat nieuwe instappen tussen 22:00 en 02:00 UTC zijn toegestaan, inclusief start en exclusief einde. De broker wisselt volgens zijn zomertijdschema van UTC+2 naar UTC+3. De handelsregel blijft aan UTC verankerd; alleen de getoonde servertijd wijzigt.

Nachtsessie bij verandering van servertijd
UTC-event Server op UTC+2 Server op UTC+3 Nieuwe instap
21:59:59 23:59:59 00:59:59 Geblokkeerd
22:00:00 00:00:00 01:00:00 Toegestaan
01:59:59 03:59:59 04:59:59 Toegestaan
02:00:00 04:00:00 05:00:00 Geblokkeerd; open posities blijven beheerd

Kalender-events bewaren provider-ID, oorspronkelijke en gewijzigde tijd, impact, valuta, ophaaltijd en dataleeftijd. Een dubbel ID wordt genegeerd; een revisie vervangt de toekomstige planning met log. Bij stale feed of refreshfout worden nieuwe instappen geblokkeerd wanneer nieuwspermissie vereist is, terwijl beschermende exits actief blijven. Een late tick gebruikt de huidige toestemming.

Meet het filter met twee replays van dezelfde strategie en tickdata, waarbij alleen de bevroren permission stream verschilt. Trades achteraf uit een rapport wissen reproduceert geen vertraagde signalen of ander positiepad. Publieke data telt 7 exacte tijd/sessielabels en 3 nieuwslabels die kunnen overlappen; de oudere selectie van 13 heeft een ongepubliceerde bredere scope.

Wat te controleren

  • Test een nachtsessie, beide grenskeuzes en de klokwissel van de broker.
  • Herhaal stale, dubbele en herziene kalender-events plus een late eerste tick.
  • Scheid toestemming voor instap, beheer van open posities en noodexit.

Grenzen van dit voorbeeld

Dit voorbeeld gebruikt UTC-beleid. Een broker-sessiebeleid kan ook, mits klok en zomertijdbron expliciet zijn.

Redactioneel eigenaarschap en primaire bronnen

Beoordeeld door POLARIS Research

Bewijskader

Dit artikel combineert officieel platformgedrag met terugkerende, geanonimiseerde implementatiepatronen. Exacte handelsregels en klantmateriaal zijn uitgesloten.

Primaire bronnen

Deze bronnen ondersteunen platformgedrag of onderzoeksconcepten. Ze valideren geen POLARIS-prestaties en garanderen geen toekomstige resultaten.

Verken de volgende relevante laag

Ga gericht verder tussen onderzoek, systeemengineering en portefeuilleconstructie zonder de context van deze pagina te verliezen.

Neem contact op met POLARIS via WhatsApp