Juridisch validatiedossier

Simpel gezegd: Als wij geld (stablecoins) van gebruikers vasthouden, zien de EU-cryptoregels ons misschien als een soort bewaarbank — en daar heb je een vergunning voor nodig. De kernvraag: hoe lang mag geld “onderweg” zijn voor het juridisch “bewaren” heet?

STANDPUNT: het aanhouden van stablecoin-saldi voor gebruikers is vermoedelijk “bewaring en beheer van cryptoactiva voor derden”; pure doorstroom binnen dezelfde transactie mogelijk niet.

1. Is saldo-aanhouden in onze treasury CASP-plichtig — ja/nee?
2. Wat is de maximale “doorstroomtijd” waarbinnen wij géén custody zijn?
3. Is escrow-per-taak (geld geblokkeerd tot verdict) custody of contractuele derdengelden?

STATUS: testnet; treasury spend-caps live; geen echte waarde vóór dit antwoord.

Simpel gezegd: Geld ontvangen en doorbetalen voor ánderen is streng vergund werk. Onze truc: een vergunde partij (Stripe) raakt het geld aan, wij nooit. Vraag 57 is dé startvraag: mogen we nu al verdienen zolang elk bedrag gewoon betaling voor onze eigen dienst is?

STANDPUNT: fiat-ontvangst en -uitbetaling namens derden is vergunningsplichtig, tenzij volledig via een vergunde partij (Stripe Connect) waarbij wij nooit fondsen aanraken.

57. Klopt het dat wij zonder vergunning mogen starten zolang geld enkel naar ONS stroomt als betaling voor onze eigen dienst, en er niets doorstroomt naar derden? Waar ligt exact de grens? PRIO A
4. Welke Stripe-Connect-variant kwalificeert als “wij raken geen fondsen aan”?
5. Geldt de commercial-agent-uitzondering voor een tweezijdige marketplace — ja/nee?
6. Money-remittance-licentie nodig als (4) klopt — ja/nee?

Simpel gezegd: Een saldo dat je kunt opnemen is “elektronisch geld” als wíj het uitgeven — dan ben je bijna een bank. Staat datzelfde saldo bij de vergunde partij, dan niet. Eén vraag, groot verschil.

STANDPUNT: een opneembaar euro-“inbox-saldo” is e-money als wíj het uitgeven; niet als het bij de vergunde partij staat.

7. Klopt die lijn?
8. Verandert het antwoord als het saldo in stablecoins luidt?

Simpel gezegd: België heeft sinds 1 juli een eigen registratieregel bij de toezichthouder (FSMA). We moeten exact weten welke handeling de bel doet rinkelen — en wat de boete is als je hem mist.

9. Welke activiteit triggert exact FSMA/NBB-registratie?
10. Sancties bij ontbreken?
11. De-minimis- of overgangsregime — ja/nee?

Simpel gezegd: Witwaswetten eisen twee dingen tegelijk: weten dat je klant echt is, én op gerechtelijk bevel kunnen tonen wie het was. Onze verzegelde kluis die alleen op bevel opengaat is precies dat — de vraag is of de wet het ook zo leest. Hier zitten ook de sleutelvragen uit het 🔑 Sleutels-dossier (54, 58, 59).

STANDPUNT (herzien 11-08-2026, zie V12): attestaties verkopen staat niet in de limitatieve lijst van de wet van 18/9/2017 — wij zijn vermoedelijk géén onderworpen entiteit. Dat is het scharnier: valt die kwalificatie toch anders uit, dan blijft ons sealed-maar-revealbaar-model AML-compatibel (bewaren én kunnen openen onder bevel), waar pure-ZK-modellen falen. V13 en V14 hangen conditioneel aan deze uitkomst.

Vervangen standpunt (tot 11-08-2026): wij worden vermoedelijk onderworpen entiteit; ons sealed-maar-revealbaar-model is precies wat AML vereist, en pure-ZK-modellen falen hier. Herzien na het vooronderzoek bij V12. Bewust laten staan zodat zichtbaar blijft dat het standpunt is gewijzigd en niet stilzwijgend is verschoven.

12. Onderworpen entiteit — ja/nee, en vanaf welk moment?
13. Volstaat eID-verificatie → salted hash + sealed token als identificatie- én bewaarplicht tegelijk?
14. Is “audit-only re-identificatie” AML-conform?
15. Bewaartermijn sealed token — 10 jaar?
16. Binnen welke termijn moeten wij op een bevel kunnen antwoorden?
17. Volstaat één operator-key met gelogde toegang, of is een vier-ogen-/notarisconstructie vereist?
54. Aanvaardt u een sleutelsplitsing 2-van-3 met ARTES als houder als aantoonbare waarborg dat de operator niet zelfstandig kan re-identificeren? Wil ARTES die rol opnemen, en bij welk soort bevel geeft u uw deel vrij? PRIO A
58. Volstaat AWS KMS in EU-regio (Frankfurt/Parijs) juridisch voor de afleidingssleutel, of vereist de Amerikaanse CLOUD Act een Europese provider (bv. OVHcloud) om “wij kunnen zelf niet terug” technisch én juridisch waar te maken? PRIO A
59. Maakt het uitbesteden van de HSM/KMS aan een cloudprovider die provider een GDPR-verwerker, met een verwerkersovereenkomst en extra verplichtingen tot gevolg? PRIO A
18. Transactiemonitoring + CFI-meldplicht — welke drempels?

STATUS: architectuur ondersteunt dit al (sealed token, aparte key, logging gepland).

Simpel gezegd: De privacywet. Kernvragen: mogen wij een nummer afleiden zodat niemand twee keer kan intekenen, is onze belofte-taal (“pseudoniem, verzegeld, alleen onder wettig bevel”) juridisch zuiver, en moeten we vooraf een verplichte risico-analyse (DPIA) maken?

STANDPUNT: DPIA is vermoedelijk verplicht (eID-data op schaal); rechtsgrond voor audit-re-identificatie is wettelijke verplichting.

19. DPIA verplicht — ja/nee?
20. Correcte rechtsgrond per verwerking (verificatie / bewaring / reveal)?
21. Bewaartermijnen per datacategorie?
22. Is onze publieke wording (“pseudoniem, verzegeld, alleen onder wettig bevel”) juridisch zuiver?
55. Welk identificatienummer mogen wij afleiden om te garanderen dat iemand zich maar één keer inschrijft — volstaat het itsme-nummer, of hebben wij het rijksregisternummer nodig, en mag dat? PRIO A
56. Mogen wij een versleutelde vergelijking uitvoeren tegen een gemeentelijke rechthebbendenlijst, en wat is de juiste grondslag en rolverdeling? PRIO A

STATUS: wording-fix doorgevoerd; k-anonymity-lijn voor aggregaten gedefinieerd.

Simpel gezegd: Jij geeft je robot een boodschappenlijstje met limiet: max €50, alleen deze week. Telt dat als een echte volmacht voor de wet? En wie betaalt als de robot búitén het lijstje gaat — jij, wij, of de winkel?

STANDPUNT: een door de mens getekend, gelimiteerd en intrekbaar agent-mandaat is een volmacht met bewijswaarde onder eIDAS-e-handtekening-regels.

23. Klopt de volmacht-kwalificatie?
24. Wie draagt de schade als een agent buíten zijn mandaat handelt — gebruiker, wij, of afnemer van het bewijs?
25. Welke vormvereisten maken het mandaat afdwingbaar (gekwalificeerde handtekening nodig — ja/nee)?
26. Moet intrekking derden-werking hebben en hoe snel?

Simpel gezegd: Wat als iemand sterft, zijn eID kwijtraakt of wilsonbekwaam wordt? Wie erft het saldo, wie mag dan beslissen, en wanneer móéten wij bevriezen? Dit vergeten is dé klassieke fout van identiteitssystemen.

27. Overlijden: wie erft saldi/lopende payouts, en wat is onze meld-/bevriezingsplicht?
28. Wilsonbekwaamheid/bewindvoering: wie mag dan mandateren?
29. Is er een wettelijke her-verificatie-cadans of bepalen wij die zelf?
30. Revocation: meldplicht aan afnemers van eerder afgegeven bewijzen — ja/nee?

Simpel gezegd: Dieven gaan niet de kluis kraken — ze proberen het uítbetaaladres te wijzigen (digitale zakkenrollerij). Hoe streng moet onze rem zijn, en mogen we bij twijfel bevriezen zonder zelf in de fout te gaan?

STANDPUNT: account-takeover via adreswissel is ons grootste operationele aansprakelijkheidsrisico; sterke authenticatie + wachttijd + notificatie is de zorgvuldigheidsnorm.

31. Wat is de wettelijke zorgplicht-lat bij takeover-schade?
32. Beperkt een goed recovery-ontwerp onze aansprakelijkheid aantoonbaar — ja/nee?
33. Mogen wij payouts unilateraal bevriezen bij fraudevermoeden zonder wanprestatie te plegen?

Simpel gezegd: Wie geld uitkeert moet checken dat de ontvanger niet op een sanctielijst staat, en soms informatie met de betaling meesturen. Vanaf welke euro geldt dat voor ons — en geldt het ook als we namens een overheid uitkeren?

STANDPUNT: zodra wij uitkeren, moeten wij screenen tegen de EU-geconsolideerde sanctielijst; de EU Transfer of Funds Regulation raakt onze crypto-payouts vermoedelijk vanaf de eerste euro.

34. TFR van toepassing op onze payout-flows — ja/nee, en welke gegevens moeten mee?
35. Screening-frequentie (per payout of periodiek)?
36. Proces bij hit/false positive — bevriezen + melden aan wie?
37. Geldt dit ook voor 0%-burgeruitkeringen namens een overheid, of ligt de plicht dan bij die overheid?

Simpel gezegd: Overheidsklanten eisen dat data in de EU blijft en dat er met elke partij die eraan raakt (Fly, Cloudflare, Stripe) een contract ligt dat zegt wat zij wel en niet mogen.

38. Verwerkersovereenkomsten nodig met Fly/Cloudflare/Stripe — en volstaan hun standaard-DPA’s?
39. Is EU-regio-hosting contractueel afdwingbaar genoeg voor overheidsklanten?
40. Doorgifte buiten EU (US-partijen) — welke grondslag?

Simpel gezegd: Twee geldvragen: zijn onze eigen fees op zich vergunningsplichtig? En bij 0%-uitkeringen — wie houdt de belasting in, wij of de opdrachtgever? Plus de stip op de horizon: het officiële EU-keurmerk (QTSP).

41. Kwalificeren onze fees (x402-toegang, attestatie, LAM-licenties) als iets vergunningsplichtigs op zich — ja/nee?
42. Fiscale behandeling van 0%-uitkeringen: inhoudingsplicht bij ons of bij de opdrachtgever?
43. QTSP-route (eIDAS-kwalificatie): realistische vereisten en volgorde — de moeite om nu in te tekenen of pas bij schaal?

Simpel gezegd: Moet R4M een eigen vennootschap worden vóór er echt geld stroomt — zodat een ramp niet heel Turbeau2Rock meesleurt — en welke verzekering dekt een hack of verlies van fondsen?

44. R4M onder Turbeau2Rock CommV houden of aparte entiteit vóór echt geld — en welke vorm?
45. Bestuurdersaansprakelijkheid bij hack/verlies van gebruikersfondsen — afdekbaar met beroeps-/cyberverzekering?
46. Triggert een US-contract (Circle-klasse) Amerikaanse money-transmitter-vragen aan onze kant — ja/nee?

Simpel gezegd: Is onze bewijsketen dat dit óns idee is (i-DEPOT + Bernstein-blockchain-spoor) waterdicht, en moet de geheimhoudingsovereenkomst (NDA) mee-evolueren nu de strategie groeit?

47. Volstaat i-DEPOT #1 + gepland i-DEPOT #2/annex + Bernstein-keten als bewijslijn, of ontbreekt er een schakel?
48. Moet het NDA-object geüpdatet worden nu maX de strategie uitbreidt — ja/nee?

Simpel gezegd: De AI-wet raakt ons niet als maker (er zit geen AI in ons identiteitspad). Sinds 2 augustus moet een AI-agent melden dát hij een AI-systeem is — meer eist de wet niet. Wie er achter die agent staat hoeft hij níét te melden, en dát is precies wat de markt wél wil weten. Ons mandatenblok levert dat bewijs. Geen plicht bij de klant dus, maar een gat vóór ons: voorsprong, geen compliance-argument.

Vervangen standpunt (tot 14-08-2026 16:38): sinds 2 augustus moet elke AI-agent melden naméns wie hij handelt — en dát bewijs is precies wat ons mandatenblok levert. Een plicht bij de klant wordt een product bij ons. Herzien: art. 50(1) verplicht alleen het melden dát het een AI-systeem is; “namens wie” valt er níét onder. Bewust laten staan zodat zichtbaar blijft dat het standpunt is gewijzigd en niet stilzwijgend is verschoven. Zie V50 en x401 · de verkoopdeur.

STANDPUNT: R4M valt buiten het toepassingsgebied van de AI Act. Er zit geen AI-systeem in ons identiteitspad en geen biometrie in ons register — wij vergelijken onomkeerbare codes met codes. Bijlage III, art. 5(1)(e) en art. 50(3) zijn dus niet van toepassing.

CORRECTIE 2026-08-02: de eerdere formulering (“de AI Act wordt grotendeels van toepassing vanaf augustus 2026”) is achterhaald. De Digital Omnibus (Verordening (EU) 2026/1744, van kracht 27 juli 2026) stelde de hoog-risicoverplichtingen uit naar 2 dec 2027 (bijlage III) en 2 aug 2028 (bijlage I). Sinds 2 aug 2026 geldt alleen artikel 50 (transparantie), en dat raakt ons niet als aanbieder.

Waar het ons WEL raakt is commercieel: art. 50(1) verplicht sinds 2 aug 2026 dat een AI-agent die een natuurlijke persoon aanschrijft meldt dát hij AI is, tenzij dat voor een oplettend mens evident is. Daar stopt de plicht. “Namens wie” staat er níét in — dat is geen verplichting bij onze klanten maar een onbezet gat: élke leverancier bouwt nu het AI-label; aan de tegenhanger wórdt gebouwd (Skyfire, Visa, Mastercard, Google en Okta — gemeten 14-08-2026), maar geen van hen wortelt dat in een EU-overheids-eID. Ons mandatenblok (D2: beperkt, intrekbaar, gelogd, mens in controle) is het bewijsstuk voor dát smallere gat — zie de meting op x401. Verkoop het dus als voorsprong op een gat dat de markt vraagt, nooit als een wettelijke plicht die de klant al heeft.

Vervangen standpunt (tot 14-08-2026 16:38): art. 50(1) verplicht sinds 2 aug 2026 dat een AI-agent die een natuurlijke persoon aanschrijft meldt dát hij AI is én NAMENS WIE hij handelt … Dat maakt van een complianceplicht bij onze klanten een verkoopbaar product bij ons. Herzien: de plicht dekt alleen het eerste deel. Verkopen als complianceplicht zou een klant een verplichting aanpraten die de wet niet oplegt. Bewust laten staan als spoor van de wijziging.

49. Bevestigt u dat R4M volledig buiten de AI Act valt, en welke schriftelijke scopeverklaring volstaat om dat aan klanten en toezichthouders te tonen zonder dat zij zelf de wet moeten uitpluizen?
50. Sinds 2 augustus 2026 moet een AI-agent die iemand aanschrijft melden dát hij AI is; “namens wie” valt níét onder die plicht. Kunnen wij ons mandaten- en loggingontwerp verkopen als het bewijsstuk waarmee onze klanten aan die plicht voldoen — en zo ja, hoe formuleren wij dat zonder juridische garantie te geven?

Simpel gezegd: Nieuwe EU-wet: wordt jouw software actief aangevallen, dan moet je dat binnen 24 uur vooraf en 72 uur volledig melden. Raakt vooral Secure Mail als installeerbare app — en bepaalt dus mee de lanceerdatum (vóór of ná 11 september).

STANDPUNT: wij hadden dit niet ingecalculeerd. Vanaf 11 september 2026 geldt voor software op de EU-markt een meldplicht voor actief uitgebuite kwetsbaarheden en ernstige incidenten (24 uur vroege waarschuwing, 72 uur melding, daarna eindrapport, aan CSIRT en ENISA). Secure Mail is plausibel een “belangrijk product klasse I of II”. De plicht ontstaat pas bij het op de markt brengen. R4M draait als gehoste dienst en is daardoor beperkt blootgesteld; Secure Mail als installeerbare app niet.

52. Valt Secure Mail onder de Cyber Resilience Act, en zo ja in welke categorie — en wat betekent de meldplicht vanaf 11 september 2026 concreet voor een eenmanszaak?
53. 52a. Wat verandert er als wij pas ná die datum uitbrengen?
54. 52b. Verkleint een webversie in plaats van een geïnstalleerde app het toepassingsgebied?
55. 52c. Klopt het dat wij vijf jaar beveiligingsupdates moeten garanderen, en is dat contractueel te beperken?

STATUS: lanceerdatum Secure Mail nog niet vastgelegd — dat is de beslissing waar alles aan hangt.

Simpel gezegd: Vanaf 9 december is software juridisch een product zoals een wasmachine: schade betekent betalen, ook zónder dat iemand een fout bewijst. Samen met G17 één machine: “hou het veilig en meld” — en deed je dat niet, dan betaal je.

STANDPUNT: vanaf 9 december 2026 is software juridisch een product. Wie schade lijdt, ook door verlies of beschadiging van data, hoeft geen fout meer te bewijzen. Wij kunnen dat niet wegbedingen tegenover benadeelden. Samen met de CRA vormt dit één machine: de CRA zegt “hou het veilig en meld”, de productaansprakelijkheid zegt “deed je dat niet, dan betaal je zonder dat iemand schuld moet aantonen”.

53. Wat verandert er concreet voor R4M en Secure Mail vanaf 9 december 2026?
54. 53a. Sluiten standaard beroepsaansprakelijkheidspolissen software- en AI-claims uit, en welke polis dekt dit wel?
55. 53b. Beperkt aantoonbaar goede beveiliging en tijdig patchen onze blootstelling?

Simpel gezegd: Gewoon praktisch: doet advocatenkantoor ARTES alles zelf, of halen ze er onder hun leiding een specialist bij voor het bank- en cryptoluik?

51. Neemt ARTES het financieel-regulatoire luik (G1–G5: MiCA/CASP, PSD2, e-money, FSMA) zelf, of halen we daar een gespecialiseerde confrater bij onder uw regie? Samenstelling van het team is volledig uw keuze — wij vragen alleen need-to-know gezien i-DEPOT/NDA-lijn.