De meest voorkomende Python fouten in trading scripts (en de oplossing)
Je staat te trappelen. Je script draait, je broker-API knippert groen, en je ziet die eerste trades live de markt in gaan. En dan: bam. Een error.
Je bot crasht, een order gaat niet door, of erger: hij koopt per ongeluk 1000 aandelen in plaats van 10. Het voelt frustrerend, alsof je net iets te vroeg juicht. Maar maak je geen zorgen, dit overkomt iedereen.
Zelfs de beste algoritmische traders lopen tegen dezelfde muur aan. Laten we samen de meest voorkomende Python-fouten in trading scripts bekijken en hoe je ze fixt, zonder dat je een cursus computerwetenschappen hoeft te doen.
Fout 1: De ongrijpbare API-tijdslimiet
Stel je voor: je backtest draait soepel op je lokale machine, maar zodra je live gaat met Interactive Brokers of Binance, verdwijnt je data ineens in het niets.
Je script probeert een koers op te halen, maar de broker-API gooit roet in het eten met een timeout of een rate limit. Het gebeurt vaak als je in een heet moment, zoals een rentebesluit van de ECB, te snel te veel requests stuurt. Waarom gaat het mis?
Brokers zoals Alpaca of DEGIRO limiteren het aantal verzoeken per minuut om hun servers te beschermen. Een script dat zonder pauze blijft vragen om data, krijgt een 429-fout (te veel verzoeken) of een timeout. De gevolgen?
Je mist een cruciale entry, of je bot denkt dat de markt is ingestort terwijl hij gewoon geen antwoord krijgt.
Dat kan leiden tot verkeerde beslissingen en onnodige verliezen, soms wel €50 tot €200 per misstap. De oplossing is simpel: bouw een wachtrij in met time.sleep() of een library zoals requests.Session met een retry-mechanisme. Gebruik een decorator of een eenvoudige functie die elke request pauzeert met 0.1 tot 0.5 seconden, afhankelijk van je broker. Test dit eerst met een demo-account bij bijvoorbeeld Interactive Brokers om te zien hoe snel je limiet bereikt wordt.
Fout 2: Verkeerde datatype in je order
Een typisch scenario: je script berekent een positie van 100 aandelen op basis van je risicomanagement-regel, maar als je de order plaatst via de API, krijg je een error omdat je per ongeluk een string stuurt in plaats van een float. Dit gebeurt vaak bij het parsen van CSV-data uit een backtest of het ophalen van JSON van je broker.
Het misgaat komt omdat Python flexibel is, maar APIs streng. Je script zegt "koop 100", maar de API verwacht 100.0 als getal.
De gevolgen zijn direct: de order faalt, je bot stopt, en je mist een trade die je risicomanagement had goedgekeurd. In een volatiele markt zoals crypto op Binance kan dit binnen seconden €10-€50 aan gemiste kansen kosten. Fix dit door altijd expliciet te typen.
Gebruik float() of int() waar nodig, en voeg een try-except blok toe rond je API-call. Bijvoorbeeld: als je een waarde uit een dictionary haalt, check dan met isinstance(value, (int, float)).
Voor backtesting met libraries als Backtrader of Zipline, zorg dat je dataframes de juiste dtypes hebben via pandas.astype(). Dit voelt als een kleine moeite, maar het redt je bot van crashes.
Fout 3: Geen error handling voor API-fouten
Je script draait, plots crasht het omdat de broker-API een onverwachte fout geeft, zoals een verbroken verbinding tijdens een marktschommeling. Geen waarschuwing, gewoon zwart scherm.
Dit overkomt beginners vaak als ze niet testen met echte API-keys, maar met mock-data. Waarom? Brokers zoals Kraken of eToro kunnen tijdelijk offline zijn, of je internet knippert.
Zonder error handling stopt je script abrupt, en als je bot een open positie heeft, blijft die open zonder stop-loss. De gevolgen?
Risico op grotere verliezen, soms €100+ als de markt tegen je beweegt, en je moet handmatig ingrijpen. Los het op met een breed try-except blok rond elke API-interactie. Vang specifieke errors zoals requests.exceptions.RequestException of de broker-specifieke codes (bijv. IB's ConnectionError). Log de error met logging-module naar een bestand, zodat je later kunt debuggen.
Voeg een fallback toe: als de API faalt, gebruik dan lokale data of sluit de positie automatisch. Zo blijft je bot stabiel, zelfs als de broker even hapert.
Fout 4: Onjuiste tijdzones in data
Je backtest ziet er perfect uit met data van 9:00 uur 's ochtends, maar live op de Euronext-beurs loopt je script uit de pas omdat de tijdzones niet kloppen. Je script denkt dat het 10:00 is, maar de markt is al dicht of open op een ander moment.
Dit gebeurt omdat Python's datetime standaard UTC gebruikt, maar brokers zoals Interactive Brokers vaak lokale tijd (bijv. CET voor Europa) of UTC+0 voor crypto. In een backtest met historical data van Yahoo Finance of Alpha Vantage, mix je zones zonder het te merken.
Gevolg: je bot execute trades op verkeerde momenten, zoals kopen tijdens een dichte markt, wat leidt tot errors of verkeerde fills voor €20-€100 per fout.
De praktische oplossing: gebruik altijd timezone-aware datetime objecten met de pytz-library. Zet alles om naar UTC bij het inladen van data, en pas lokale tijd toe bij het plannen van orders. Bijvoorbeeld: df['timestamp'] = pd.to_datetime(df['timestamp']).dt.tz_localize('UTC').dt.tz_convert('Europe/Amsterdam'). Test je script met een kalender van de beurs om timings te controleren. Zo voorkom je verwarring en blijft je risicomanagement op schema.
Fout 5: Geen validatie voor risicomanagement parameters
Stel: je script laadt een configuratiebestand voor je bot, met stop-loss op 2% en position size van €500. Maar door een typfout in het JSON-bestand, wordt de stop-loss 20% in plaats van 2%, en je bot riskeert te veel op een enkele trade.
Waarom mislukt dit? Zonder validatie aanvaardt Python elke invoer, zelfs als die onlogisch is.
In trading scripts, waar je met echte centen werkt, is dit gevaarlijk. Gevolgen: overmatig risico, zoals een verlies van €500 op een trade die bedoeld was voor €50, of zelfs een margin call bij je broker. Los het op met een simpele validatiefunctie.
Gebruik libraries zoals Pydantic of een eigen check: als stop_loss > 0.05 (5%), gooi een ValueError en stop het script. Sla je configuratie op in een YAML-bestand en laad het met json.load, maar voeg assertions toe voor elke parameter. Voor backtesting met libraries als QuantConnect, test je trading bot functies altijd eerst op historische data om te zien of je risicogrenzen kloppen.
Fout 6: Geheugenlek door oneindige loops in live bots
Je live bot draait in een while True-loop om voortdurend marktdata te monitoren, maar na een uur crasht je computer omdat het geheugen volloopt.
Dit zie je vaak bij scripts die data accumuleren zonder op te ruimen, zoals een lijst met alle trades die ooit zijn gemaakt. Waarom gebeurt dit?
Python houdt objecten in geheugen tenzij je ze expliciet verwijdert. In een trading bot die elke seconde data verwerkt, groeit een list of dictionary snel. Gevolgen: je bot stopt, je mist trades, en bij een volatiele markt zoals forex op MetaTrader verlies je €10-€50 per minuut downtime. De oplossing: beperk de data-opslag.
Gebruik een deque uit collections voor een vaste buffer (bijv. max 1000 candles), en leeg deze regelmatig.
Voeg gc.collect() toe na elke cyclus om geheugen vrij te maken. Voor live bots, overweeg een scheduler zoals APScheduler in plaats van een eindeloze loop, zodat je taken pauzeert. Test dit tijdens een backtest om te zien hoeveel geheugen je bot verbruikt.
Fout 7: Onduidelijke logging voor debugging
Je bot draait, maar als er iets misgaat, zie je alleen cryptische print-statements of helemaal niets. Ontdek hoe je een bot debugt die geen orders plaatst, terwijl je broker-API al lang een foutmelding gaf.
Dit is een klassieker: te weinig of te veel logging zonder structuur. In complexe scripts met meerdere threads voor data en orders, raak je het overzicht kwijt. Gevolgen: langere debug-tijd, misschien wel uren, en onnodige verliezen omdat je niet snel kunt inspringen. Zorg ook voor een stabiele omgeving met een requirements.txt of Poetry file.
Zet in op gestructureerde logging met de logging-module van Python. Stel een logger in met niveaus (DEBUG, INFO, ERROR) en schrijf naar een bestand en console.
Preventieve checklist voor je trading scripts
- Test elke API-call eerst met een demo-account bij je broker (bijv. €100 speelgeld).
- Gebruik altijd type-hints en validatie voor invoer, zoals stop-loss tussen 1-5%.
- Implementeer retry-logica met exponential backoff voor API-limits (wacht 1s, dan 2s, etc.).
- Log elke actie met timestamps en context, en check geheugengebruik na lange runs.
- Valideer tijdzones en data-dtypes voor backtesting en live trading.
- Houd je risicomanagement simpel: max 2% per trade, diversifieer over 5-10 posities.
- Update je dependencies regelmatig (bijv. pip install --upgrade requests) om bugs te voorkomen.
Bijvoorbeeld: logging.info(f"Order geplaatst: {symbol} @ {price} voor {amount} stuks"). Voeg timestamps toe en log specifiek voor trading-elementen zoals API-responses en risico-berekeningen. Gebruik tools als Loguru voor nog meer gemak. Zo vind je fouten snel, zonder je hoofd te breken.
Met deze aanpak voelt debuggen niet als een straf, maar als het verfijnen van je bot. Je bent er bijna – blijf experimenteren en je scripts zullen rocken.