Architectuur — een 9-service trading-platform.
Hoe een experimenteel handelsplatform met negen onafhankelijke services 24/7 draait, en hoe dezelfde architectuurprincipes zich vertalen naar workflow-automatisering voor klanten.
AlphaPPO is onze eigen R&D-omgeving — een experimenteel handelsplatform dat wij in eigen beheer ontwikkelen om de engineering-discipline op te bouwen die wij vervolgens op klantopdrachten toepassen. Het systeem draait op simulatie-rekeningen via geregistreerde broker Alpaca; er gaat geen echt geld om. Wij bieden het niet aan als product, dienst, of investeringsvehikel. Wij benadrukken dit omdat het belangrijk is dat u weet wat u leest: een case study over engineering, geen prospectus voor een financieel product.
Negen markten, gesimuleerde portefeuille, reinforcement learning.
AlphaPPO is een handelsplatform dat negen financiële markten 24/7 monitort en autonome handelsbesluiten neemt op een gesimuleerde portefeuille van $100.000. De besluitvorming komt voort uit reinforcement learning — een vorm van machine learning waarbij het systeem strategieën leert door experimenten op historische data. De negen markten zijn zes Amerikaanse beurs-ETF's (SPY, QQQ, IWM, GLD, SLV, TLT en ITA) plus twee cryptocurrencies (Bitcoin en Ethereum). De handel verloopt via Alpaca's paper-trading API: elke transactie wordt geregistreerd alsof het echte geld is, maar er beweegt geen kapitaal.
Wij bouwen het sinds zes maanden, in de avonden en weekenden. Het is geen revolutionair financieel idee — RL-gebaseerde handelssystemen zijn een bekende categorie en de meeste werken niet — maar het is een legitiem technisch project. De interessante kant zit in de engineering, niet in de strategie.
Falen op één plek tegelijk, niet als geheel.
De kern van het systeem is bewust opgesplitst. Elke van de negen markten heeft een eigen service die onafhankelijk draait, met een eigen configuratie, een eigen logging-stroom, en een eigen runtime-status. Een crash in de SPY-service heeft geen impact op de service voor goud (GLD); een onverwachte herstart in ETH raakt de Treasury-bonds-service (TLT) niet.
Deze opsplitsing kost meer dan een monolithisch ontwerp — meer processen, meer configuratie, meer monitoring-punten. Maar de reden is operationeel: een systeem dat continu draait moet falen op één plek tegelijk, niet als geheel. Voor een trading-platform is dat het verschil tussen «één positie onbedoeld open» en «portefeuille leeggetrokken.» Voor een klant-werkflow is het het verschil tussen «facturatie-stap haperde, andere stappen werken» en «de hele werkflow viel om.»
Boven de negen services draait een centrale configuratielaag die ze coördineert — risico-parameters, marktregime-classificatie, portefeuille-rebalancing — zonder dat de individuele services daarvan afhankelijk zijn voor hun primaire functie.
Vier subsystemen die de operationele betrouwbaarheid definiëren.
Op die centrale laag zitten vier subsystemen die de operationele betrouwbaarheid van het platform definiëren:
- Risk managementDrie afzonderlijke lagen voor verlies-controle: een drawdown-controller die het systeem pauzeert bij portefeuille-verlies boven een drempel, trailing stop-losses die winsten vastleggen wanneer een positie omslaat, en een daily circuit breaker die alle handel staakt als de dagelijkse verliezen een limiet bereiken. Drie lagen omdat één laag — wat het ook is — een single point of failure is.
- Regime-detectieEen Hidden Markov Model (HMM) classificeert de huidige marktomgeving (hoge volatiliteit, lage volatiliteit, sterke trend, range-bound) en past aan hoe agressief het systeem handelt. Een tweede, eenvoudiger detector loopt parallel als backup; als de twee detectoren wezenlijk verschillen, wordt dat als signaal voor manuele review gemarkeerd.
- Wekelijkse rebalancingElke zondagochtend om 4:00 UTC herbalanceert het systeem de portefeuille op basis van de correlaties tussen de negen markten. Geen handmatige tussenkomst, geen vergeten weekend.
- ObservabilityEen live Datadog-dashboard toont real-time prestaties, posities en systeemstatus. Daarnaast: dagelijkse e-mail-samenvattingen, Telegram-notificaties bij specifieke gebeurtenissen, en een watchdog-proces dat detecteert als een service onbedoeld is gestopt.
655 tests vóór een wijziging in productie komt.
Wijzigingen aan strategie of code lopen door 655 geautomatiseerde tests vóór ze worden uitgerold. Een continuous-integration pijplijn op GitHub Actions checkt elke push. Strategie-aanpassingen lopen aanvullend door een rolling-window backtest met statistische-significantie-tests — een mechanisme dat in case study 2 dieper aan bod komt.
Niet identiek toegepast — wel als basishouding.
Bij een klantopdracht — een werkflow voor een accountantskantoor of MKB — gaan dezelfde principes mee, niet identiek toegepast maar wel als basishouding:
- Werkflow-stappen los van elkaar waar dat verstandig is — zodat een falende stap niet een hele werkflow omtrekt.
- Monitoring is geen optie maar onderdeel van het ontwerp — wij leveren elke werkflow op met logging en alerting waar dat past.
- Tests vóór productie niet 655 — een typische werkflow heeft die schaal niet nodig — maar wel de tests die de werkflow waarmaken.
- Validatie is doorlopend niet eenmalig. Een werkflow die werkt op de dag van oplevering moet ook werken zes maanden later, en daarvoor moet de werkflow zelf in staat zijn om te tonen dat hij werkt.
Wij bouwen geen trading-systeem voor uw kantoor. Wat wij wel doen, is de discipline die wij op onze eigen R&D toepassen, vertalen naar de schaal en context van uw werkflow.
Klaar om te beginnen?
Vijftien minuten. Geen verkooppraatje. Wij bespreken uw werkflow en geven een eerlijk oordeel — Audit, Sprint, Webdesign, of geen fit.