R4M als software die de klant zélf draait

Simpel gezegd: de klant installeert onze component op zijn eigen servers. Er komt geen enkel gegeven bij ons binnen — wij zien niets, bewaren niets en verwerken niets.

Waarom dit een eigen trede is: op alle andere treden zijn wij minstens verwerker van persoonsgegevens. Hier niet: wij leveren software, meer niet. Dat haalt de verwerkersovereenkomst, de DPIA-bijdrage en het dataresidentie-vraagstuk volledig weg. Wat overblijft is productaansprakelijkheid en de Cyberresilience-verordening voor de software zelf.

De vraag: is dit een reële uitweg voor klanten met een zware inkoopprocedure — een ziekenhuis, een overheid, een bank — die ons als verwerker niet door hun audit krijgen? En verandert het iets aan onze aansprakelijkheid als het bewijs bij hen fout gaat?

R4M puur — attestatie zonder één euro

Simpel gezegd: een bedrijf vraagt ons iets en krijgt ja of nee terug. Er beweegt geen geld, in geen enkele richting. Wij bewaren geen fondsen, betalen niemand uit en raken geen munt aan.

Wat er concreet gebeurt: een klant roept ons aan met een API-sleutel, of gebruikt ons als inlogprovider. Wij antwoorden met een pseudonieme code plus één of meer claims — "één unieke mens", "18 of 21 jaar of ouder", "deze persoon mag namens deze onderneming handelen", "deze mens is al eerder gezien in deze context". Meer niet. De klant betaalt ons per maand of per licentie, met een gewone factuur.

De acht echte voorbeelden uit ons eigen verkoopdossier, en ze zitten alle acht hier: de leeftijdscontrole bij het afrekenen in een drankwebshop; de inlogschil voor gemeenten bij een participatieplatform; de uniciteitscontrole vóór uitbetaling bij handelsfirma's; de identiteitslaag vóór het gokregister en bij de platformleverancier van de Nationale Loterij; het uniciteitssignaal bij een laadpaalplatform; de toegangscontrole vóór een MCP-server; de entiteitscheck achter een rekennode. Nul geldstroom door R4M, in alle acht.

Welk recht wij hier verwachten: AVG (verwerking, dataminimalisatie, verwerkersovereenkomst, DPIA) en eIDAS/eID (betrouwbaarheidsniveau, en de registratieplicht van artikel 5b eIDAS voor elke vertrouwende partij die op de Europese wallet wil steunen — publiek én privaat, dus ook wij). Verder productaansprakelijkheid en de Cyberresilience-verordening.

Wat wij hier NIET verwachten, en dat is de vraag aan u: geen betaaldienstenrecht, geen e-money, geen MiCA, geen witwasplicht, geen vergunning. Als dat klopt, is dit de rail die zonder juridische poort de markt op kan — en dan bouwen wij daar eerst alles op. Klopt dat?

R4M met een geldstroom in euro — uitbetalen aan mensen

Simpel gezegd: hier stroomt er wél geld, in gewone euro's, en het gaat naar een mens toe. De eigenaar van een thuisbatterij of een laadpaal krijgt zijn machine-omzet via ons uitbetaald, met een publiek controleerbaar kasboek als bewijs dat elke euro aankwam.

Wat er bovenop trede 2 komt: alles van trede 2 blijft gelden — wij moeten nog steeds weten wie de ontvanger is — en daar komt het betaaldienstenrecht bij. Het scharnier is of wij het geld ooit aanraken, ook al is het één seconde, of dat het rechtstreeks van betaler naar ontvanger gaat terwijl wij enkel de instructie geven.

De vragen die hier thuishoren: zijn wij betaaldienstverlener, en zo ja welke categorie? Kan het model zo gebouwd worden dat wij structureel buiten de vergunningsplicht blijven — nooit fondsen houden, werken via een vergunde partner? Wat betekent dat voor kapitaalvereiste, aansprakelijkheid en toezicht? En vanaf welk volume kantelt het?

Ons vermoeden, ter toetsing: dat de veilige weg is om nooit zelf fondsen te houden en de geldbeweging bij een vergunde partij te laten, terwijl wij enkel de identiteits- en bewijslaag leveren. Precies dat willen wij bevestigd zien vóór we één regel code schrijven.

R4M met stablecoins — en een grens die in maart 2026 verschoof

Simpel gezegd: hetzelfde als trede 3, maar het geld is een stablecoin in plaats van een euro op een bankrekening. Juridisch komt daar een compleet tweede bouwwerk bovenop.

Wat er bovenop trede 3 komt: MiCA. Precies: MiCA is van toepassing sinds 30 december 2024 (Titels III en IV, over e-money tokens, al sinds 30 juni 2024). Wat op 30 juni 2026 afliep is de Belgische overgangsregeling van artikel 143(3): sinds 1 juli 2026 heeft elke cryptodienstverlener in België een MiCA-vergunning nodig. Onze lezing is dat wij géén vergunningsplichtige cryptodienst leveren zolang wij nooit crypto bewaren, wisselen, verhandelen of uitkeren — een uniciteits-attestatie is geen van de tien vergunningsplichtige diensten. Zodra wij de munt aanraken, verandert dat.

De verschuiving die u moet kennen: de EBA gaf op 10 juni 2025 een no-action letter uit over de wisselwerking tussen het betaaldienstenrecht en MiCA (EBA/Op/2025/08), en beëindigde die overgangsperiode op 2 maart 2026 (EBA/OP/2026/01 van 12 februari 2026). Nauwkeurig: het is een handhavingsadvies aan de nationale toezichthouders, geen nieuwe vergunningsregel. Wie vóór 2 maart 2026 een volledige vergunningsaanvraag had lopen, mag onder voorwaarden verder (geen nieuwe klanten, geen marketing); alleen wie noch vergunning noch lopende aanvraag had, moet stoppen en klanten offboarden. Het wisselen van crypto tegen fondsen valt er niet onder. De rol van doorgeefluik is voor ons dus afgesloten terrein, die van ontvanger op eigen rekening niet.

Twee praktische punten die wij zelf vonden en graag bevestigd zien: gebruik euro-stablecoins in plaats van dollar-stablecoins, omdat MiCA via artikel 58(3) de artikelen 22, 23 en 24(3) van toepassing verklaart op e-money tokens in een niet-EU-munt. Nauwkeurig: artikel 23 werkt met het geschatte kwartaalgemiddelde per dag, uitsluitend voor gebruik als ruilmiddel binnen één valutagebied; pas boven één miljoen transacties én 200 miljoen euro moet de uitgever de uitgifte stopzetten en binnen veertig werkdagen een plan indienen. Niet: één dag boven de drempel. Punt voor u: artikel 58 draagt het opschrift "significante" e-money tokens terwijl lid 3 ongekwalificeerd is — een tegenpartij kan daarop drukken. En factureer maandelijks in samenvatting — nooit per transactie. Nauwkeurig: de Belgische e-facturatieplicht (wet van 6 februari 2024, artikel 53 §2 WBTW) geldt sinds 1 januari 2026, maar alleen wanneer beide partijen in België gevestigde btw-plichtigen zijn; vrijgestelden onder artikel 44 en niet in België gevestigde partijen vallen erbuiten. Peppol-BIS is daarbij de standaard, geen absolute verplichting: een ander formaat mag, zolang het voldoet aan EN 16931.

De vraag: klopt de grens die wij trekken — attestatie leveren mag zonder vergunning, munt aanraken niet? En waar ligt de grens bij een betaalhaak die wij wél aanbieden maar waarvan de afwikkeling bij een derde gebeurt?

De agent-trede — een machine handelt namens een mens

Simpel gezegd: niet een mens klikt, maar een AI-assistent doet iets namens hem. De vraag wordt: namens wie handelt dat ding, en waartoe was het gemachtigd?

Waarom dit een eigen trede is: er bestaat vandaag geen Europees rechtsfiguur voor een betaling die door een machine geïnitieerd wordt. Het betaaldienstenrecht gaat uit van een menselijke betaler en een sterke klantauthenticatie die een mens uitvoert. De nieuwe betaalwetgeving die in 2027 in werking treedt bevat er niets over. Dat is een leemte, geen detail.

Belangrijk voor de volgorde: deze trede kan óók zonder geld bestaan. Een agent die enkel data opvraagt bij een MCP-server zit op trede 2 plus de mandaatvraag — niet op trede 4. Dat is precies onze verkooppositie in dat dossier: wij leveren de toegangscontrole, niet de kassa.

Wat er wél al bestaat en waar wij tegenaan lopen: de bestaande mandaatregisters in Europa — de Nederlandse ketenmachtiging, het Belgische CSAM, het Finse register — kennen wél een machtiging met geldigheidsduur en afgebakend onderwerp, maar géén bedraglimiet, géén frequentielimiet, géén doelbinding en géén voorwaardelijke intrekking. En de mandaathouder is er altijd een genoemde natuurlijke persoon: er is geen plaats voor een machine. De Europese wallet voegt vertegenwoordiging tussen natuurlijke personen toe, noemt AI-agents nergens, en het onderdeel voor rechtspersonen staat er letterlijk als "leeg" in.

De vragen: kan een mandaat "deze agent mag namens mij tot bedrag X bij partij Y tot datum Z" naar Belgisch recht rechtsgeldig verleend worden, en wie is aansprakelijk als de agent buiten dat mandaat handelt? Is een intrekbaar, cryptografisch ondertekend mandaat afdwingbaar? En kan een ónderneming zo'n mandaat verlenen, of stuit dat op het vennootschapsrecht rond vertegenwoordigingsbevoegdheid?

Wie of wat is het subject — een mens, een onderneming, of een machine?

Simpel gezegd: Over wie gaat het eigenlijk: een mens, een bedrijf, of een apparaat? Dat zijn juridisch drie totaal verschillende dingen — en wij verkopen ze in één product. Hier zit ook de laadpaal en de thuisbatterij: dat is geen aparte trede, het is de vraag wie de eigenaar van dat ding is.

Drie totaal verschillende rechtsfiguren, en dit is waarschijnlijk de belangrijkste splitsing van allemaal.

Een natuurlijke persoon — dat is waar de AVG en het personhood-verhaal thuishoren. Bewijzen dat iemand één echte, unieke mens is.

Een onderneming — "deze persoon mag handelen namens BV X". Dat is géén AVG-vraag maar vennootschapsrecht: vertegenwoordigingsbevoegdheid, mandaat, intrekbaarheid, en wie tekent. De AVG is op de onderneming zélf niet eens van toepassing. Dit is een compleet ander juridisch gesprek dan het vorige, en wij verkopen het wél in hetzelfde product.

Een machine — de laadpaal, de thuisbatterij, de rekennode. Een machine heeft geen rechtspersoonlijkheid; ze kan niets bezitten en niets verschuldigd zijn. Hier zit de IoT-toepassing, en dat is waarom die aanvoelt als een eigen trede terwijl het er geen is: het is een subject-vraag, niet een geld-vraag. Ze doet zich voor op trede 2 (wie is de eigenaar van deze node?) én op trede 3 en 4 (naar wie mag de machine-omzet stromen?).

De vragen: hoe leggen wij de band tussen een machine en haar eigenaar juridisch vast, en wat gebeurt er bij verkoop van de machine? Wie is aansprakelijk als er via een geverifieerde node iets onrechtmatigs gebeurt — de eigenaar, het platform, of wij? En kan een onderneming een mandaat verlenen zonder tussenkomst van een notaris?

Onze rol in de gegevensketen — verwerker of verwerkingsverantwoordelijke?

Simpel gezegd: Bepalen wij zelf wat er met de gegevens gebeurt, of doen wij alleen wat de klant vraagt? Dat ene onderscheid bepaalt wie de boete krijgt als het misgaat, en wie de gebruiker te woord moet staan.

Dit staat volledig los van geld en verandert per klant. Bij de ene toepassing bepalen wij zelf doel en middelen (dan zijn wij verantwoordelijke, met eigen informatieplicht en eigen aansprakelijkheid), bij de andere handelen wij zuiver in opdracht (dan zijn wij verwerker, en volstaat een verwerkersovereenkomst).

Waarom het scherp moet: het bepaalt wie de DPIA doet, wie de betrokkene te woord staat, wie meldt bij een datalek, en wie de boete krijgt. Het bepaalt ook of wij een subverwerker mogen inschakelen zonder toestemming.

De vraag: in welke van onze acht toepassingen zijn wij verwerker en in welke verantwoordelijke — en is er een ontwerp waarbij wij consequent het lichtste van de twee zijn? En: kan een aanbieder wiens node enkel een pseudoniem is, ooit een rechtsgeldige subverwerker zijn?

Het verzegeld bewijs en de rechtmatige toegang

Simpel gezegd: Wij bewaren een gesloten envelop met de echte identiteit, die alleen op bevel van een rechter opengaat. Wie mag dat bevel geven, hoe lang bewaren we die envelop, en hoe bewijzen we dat er niet stiekem in gekeken is?

Op elke trede bewaren wij een verzegeld identiteitsbewijs dat uitsluitend onder wettig bevel opengaat. Dat is een eigen regime: wie mag het openen, op welk bevel, hoe lang bewaren wij het, wat doen wij bij een buitenlands verzoek, en hoe tonen wij aan dat er niet stiekem geopend is.

Waarom dit niet op de ladder past: het geldt even hard bij een leeftijdscontrole in een supermarkt als bij een uitbetaling in stablecoins. Het is bovendien het onderdeel waarop wij ons hele privacyverhaal bouwen — als dit niet klopt, klopt de rest ook niet.

De vragen: is onze sleutelbewaring houdbaar, en welke bevelen moeten wij honoreren? Mogen wij weigeren bij een verzoek uit een derde land? En hoe verhoudt de bewaartermijn zich tot het recht op wissing?

De sectorvergunning van de klant — die beperkt wat wij mogen

Simpel gezegd: Niet onze vergunning telt hier, maar die van de klant. Een gokbedrijf mag bepaalde lijsten alleen zelf raadplegen — dus daar mogen wij nooit tussen gaan zitten, hoe goed onze techniek ook is.

Niet ónze vergunning, maar die van de klant, en zij bepaalt de vorm van ons contract. Bij kansspelen mag het uitsluitingsregister enkel door vergunninghouders bevraagd worden — wij mogen daar dus nooit tussen gaan zitten. Bij alcohol geldt een geborgde werkwijze met inspectie. In de financiële hoek gelden leveranciersketen-eisen die op ons afkomen via hún toezicht.

Waarom het een dimensie is en geen trede: het verandert niets aan óns regime, maar alles aan wat wij contractueel mogen beloven en welk deel van de keten wij mogen aanraken.

De vraag: welke van deze sectorregimes leggen verplichtingen rechtstreeks op ons als onderaannemer, en welke enkel via het contract met de klant?

Adresseerbaarheid — als R4M een naam of nummer uitgeeft waar iets naartoe kan

Simpel gezegd: Als wij iemand een naam en een nummer geven waar geld naartoe kan, zijn wij dan een telefoonboek of een bank? Verwijzen we alleen door naar zijn eigen bankrekening, dan is het het eerste. Blijft er ook maar één seconde geld bij ons staan, dan het tweede — en dan hebben we een vergunning nodig.

Waar dit over gaat: naast bewijzen wie iemand is, overwegen wij hem ook adresseerbaar te maken — een spreekbare naam en een nummer in de vorm van een plaat, zodat een ander weet waar hij iets naartoe moet sturen. Dat is een derde ding, naast attesteren en betalen: het is opzoeken en doorverwijzen.

Waarom dit apart moet, en dit is de vraag waar alles aan hangt: een adres is juridisch iets compleet anders naargelang wat erachter zit. Als onze plaat enkel verwijst naar de eigen bankrekening van de gebruiker — zoals een telefoonboek dat een naam aan een nummer koppelt — dan houden wij niets aan en blijven wij op trede 2. Maar als er ook maar een saldo achter zit dat wij beheren, dan is het een betaalrekening en staan wij op trede 3 met vergunningsplicht. Dat is één ontwerpbeslissing die het hele regime bepaalt, en wij willen ze bewust nemen in plaats van er per ongeluk in te rollen.

Wat wij intussen zelf vonden en wat dit interessanter maakt: sinds 9 oktober 2025 moet bij elke euro-overschrijving gecontroleerd worden of de naam van de begunstigde bij het rekeningnummer hoort. Er is dus een verplichte markt ontstaan voor precies de vraag "hoort deze naam bij dit nummer" — en dat is naar zijn aard een opzoekdienst, geen betaaldienst. Dat kan een positie zijn die wij op trede 2 mogen bekleden.

De vragen: is een naam- en nummerdienst die enkel doorverwijst naar een bestaande rekening een gereguleerde dienst, of niet? Welke aansprakelijkheid dragen wij als de doorverwijzing fout is en er geld bij de verkeerde persoon terechtkomt? Mogen wij zo'n plaat intrekken of overdragen, en wat gebeurt er bij overlijden? En schuiven wij onbedoeld naar trede 3 zodra er ook maar één seconde saldo bij ons staat?

Wanneer een functie zélf een gereglementeerde vertrouwensdienst wordt

Simpel gezegd: Sommige diensten mag je in Europa alleen aanbieden als je er officieel voor erkend bent — digitale aangetekende post bijvoorbeeld. Dat wordt je niet per ongeluk, en er hoeft geen euro bij te komen kijken.

Waar dit over gaat: in onze productlijn zitten ideeën die verder gaan dan attesteren — een echtheidsvignet op e-mail, en vooral het idee van digitale aangetekende post. Dat laatste is in Europa een benoemde vertrouwensdienst met een eigen kwalificatieprocedure en eigen toezicht. Je wordt dat niet per ongeluk; je moet ervoor erkend zijn.

Waarom het een dwarsdimensie is: het staat volledig los van geld. Een aangetekende zending zonder één euro is nog steeds een gereglementeerde dienst. Het kan dus op trede 2 opduiken en daar toch een vergunningsvraag opwerpen — de enige plek waar dat gebeurt.

De vragen: vanaf welk punt wordt ons bewijs een gekwalificeerde vertrouwensdienst, en welke functies kunnen wij aanbieden zonder die kwalificatie? Mogen wij "aangetekend" of "gecertificeerd" in onze productnaam gebruiken als wij niet gekwalificeerd zijn?

Geautomatiseerde beslissingen — wat als ons antwoord iemand buitensluit?

Simpel gezegd: Ons product zegt ja of nee, en een nee heeft gevolgen: geen account, geen uitbetaling, geen stem. De wet eist dan dat er een mens aan te pas kan komen en dat je het kunt aanvechten. De vraag is of dat op ons rust of op de klant.

Waar dit over gaat: ons product geeft ja of nee, en dat antwoord heeft gevolgen. Een "nee" betekent dat iemand niet mag bestellen, niet kan stemmen, geen uitbetaling krijgt of geen account mag openen. Wij geven bovendien een graad mee die zegt hoe stevig het bewijs is, en een klant kan daarop zijn drempel zetten.

Waarom dit een eigen dimensie is: de AVG stelt bijzondere eisen aan een uitsluitend geautomatiseerd besluit met rechtsgevolgen of vergelijkbare gevolgen — recht op menselijke tussenkomst, op uitleg, en op betwisting. De vraag is of dat op ons rust, op de klant, of op beiden. Dat is niet af te kopen met een contract als het onduidelijk blijft, en het speelt op élke trede, ook bij een simpele leeftijdscontrole.

De vragen: is ons ja/nee een geautomatiseerd besluit in de zin van de AVG, of is het een feitelijke vaststelling die de klant vervolgens zélf gebruikt om te beslissen? Wie moet het herstelpad aanbieden als iemand ten onrechte geweigerd wordt — en hoe ziet dat pad eruit als wij bewust geen naam bewaren? En verandert het antwoord als wij een graad meegeven in plaats van enkel ja of nee?

Grensoverschrijding — en welke toezichthouder er dan kijkt

Simpel gezegd: Zodra je over de grens werkt, verandert de vraag wie er op je vingers kijkt. Een volmacht die in België geldt, betekent in Nederland niets.

Een Belgische eenmanszaak die een Nederlandse retailer bedient, of een Amerikaans platform met Europese gebruikers, of een node in een derde land. Dat raakt doorgifte, de bevoegde toezichthouder, en de vraag of wij een vertegenwoordiger in een andere lidstaat nodig hebben.

Waarom het overal terugkomt: op trede 2 gaat het over doorgifte van pseudonieme codes, op trede 4 over de vraag welke toezichthouder een stablecoin-stroom beoordeelt, en op trede 5 over het feit dat een mandaat uit het ene land in het andere niets betekent.

De vraag: welke toezichthouder is voor ons de eerste aanspreekbare, en verandert dat per trede? En hebben wij bij verkoop in Nederland een eigen verplichting of volstaat het Belgische kader?