Virtuele passen blokkeren? Het echte probleem ligt in governance, niet in techniek

Virtuele passen blokkeren? Het echte probleem ligt in governance, niet in techniek

Recent blokkeerden NS en andere OV-bedrijven virtuele betaalpassen wegens fraude. Het probleem: reizigers verwijderden hun virtuele kaart na het uitchecken, waardoor reiskosten niet meer geïnd konden worden. Logisch dat je dit wilt stoppen, maar de gekozen maatregel voelt disproportioneel: álle virtuele passen werden geblokkeerd. Daarmee worden ook eerlijke reizigers geraakt.

De vraag is: had dit niet slimmer gekund?

Hoe incompetentie in publieke IT-systemen ontstaat

Technisch gezien is dit probleem goed oplosbaar. Je kunt op API-niveau detaillering en controles inbouwen die fraude tegengaan zonder legitieme gebruikers te blokkeren. Toch gebeurt dat niet. Waarom niet?

1. Legacy & ketenblindheid – het OV-betalingssysteem is opgebouwd uit losse schakels (poortjes, banken, Translink), niemand overziet de hele keten.

2. Vage verantwoordelijkheid – risk, finance, legal en operations hebben allemaal een stem, waardoor de oplossing vaak de strengste (en eenvoudigste) maatregel is: een ban.

3. Gebrekkige data – metrics zijn te grof, er is geen zicht op event-level fraude.

4. Vendor lock-in – leveranciers leveren alleen wat in het contract staat; aanpassingen kosten maanden.

5. Incidentdruk – media en politiek eisen een snelle fix, dus wordt er gekozen voor een “noodrem”.

6. Compliance & privacy – DPIA’s en juridische checks vertragen innovatie.

7. Budgetstrijd – structurele oplossingen concurreren met andere investeringen.

8. Normalisering van de noodmaatregel – omdat KPI’s verbeteren, blijft de ban vaak permanent.

Kortom: de incompetentie zit niet in de techniek, maar in de governance en incentives die bepalen hoe publieke infrastructuur wordt gemanaged.

Hoe het wél kan: API-niveau oplossingen

In plaats van blanket bans kun je fraude aanpakken met slimme API’s:

• Event-sourcing: elke reis krijgt een uniek ID (journey_id).

• Hold bij incheck: bij incheck een pre-autorisatie doen (bijv. €20), die bij uitcheck wordt gecorrigeerd.

• Token-binding: een stabiele sleutel koppelen aan virtuele kaarten (hash + device ID), zodat verwijderen minder effect heeft.

• Webhook bij verwijdering: wallets sturen een signaal wanneer een virtuele kaart wordt verwijderd, zodat open transacties alsnog afgerekend kunnen worden.

• Provider-granulariteit: risico’s toeschrijven per aanbieder of device, niet per hele groep gebruikers.

• Retry & stand-in: bij mislukte betaling meerdere pogingen en fallback-opties inzetten, in plaats van blokkeren.

Met deze aanpak pak je fraude gericht aan en behoud je toegang voor de legitieme reiziger.

Waarom dit tóch niet gebeurt

Het antwoord is pijnlijk simpel: incentives. Een blanket ban levert op korte termijn meetbare resultaten op en voorkomt negatieve krantenkoppen. Een structurele oplossing vraagt samenwerking, investeringen en ownership die vaak ontbreken in publieke IT-projecten.

Maar de rekening komt later: verlies aan vertrouwen, frictie voor reizigers en structurele achterstand in innovatie.

Mijn investering als man van oplossingen

Ik geloof dat technologie ons in staat moet stellen om menselijker te zijn. Een systeem dat mensen blokkeert in plaats van faciliteert, mist dat doel. Dit is geen technisch probleem – dit is een bestuurlijk probleem. En daar ligt ook de kans.

De oplossing: detail inbouwen waar fraude ontstaat, en tegelijk vertrouwen behouden waar mensen gewoon eerlijk gebruik willen maken. Dat vraagt om leiderschap, eigenaarschap en een visie op publieke digitale infrastructuur die verder kijkt dan de volgende krantenkop.

Wat denk jij? Moet NS/TLS deze verantwoordelijkheid pakken, of accepteren we dat een blanket ban de standaard wordt in publieke dienstverlening?