MiCA 2.0 bliver vundet på ops liability – ikke på udstedelsesregler

Jeg har et enkelt bias fra at have drevet grænseoverskridende organisationer: regler beskytter ikke kunder. Det gør operating systems. Loven kan sige “authorized to issue”. Den kan definere reserver. Den kan definere disclosure. Intet af det hjælper i det øjeblik, hvor en kundes midler sidder fast mellem en EU-distributør, en ikke-EU issuer, en wallet provider, en bank og en supportindbakke, der ikke svarer.

I det øjeblik stiller kunden tre spørgsmål: Hvem tager telefonen. Hvem kan reversere. Hvem æder tabet.

Derfor tror jeg, at næste iteration af europæisk kryptoregulering – kald det MiCA 2.0 eller noget andet – ikke bliver vundet på udstedelsesregler. Den bliver vundet på ops liability og dispute plumbing. Det svære er ikke “permission to issue”. Det svære er at gøre ansvar eksplicit på tværs af distributionsstakken, på tværs af jurisdiktioner og på tværs af mellemled, der hver især har deres egne incitamenter.

Da jeg ledede en forretningsenhed på tværs af flere lande inden for smart building og home automation, var mit arbejde ikke styret af produktspecifikationer alene. Det var styret af eskalationer. En sensor, der fejler ude i felten, er ligeglad med vores org chart. Kunden vil have en tydelig ejer, en tidsplan og en løsning. I payments og tokenized money er “feltfejlen” en transfer, der sidder fast, en dobbelt debitering, en on-chain udbetaling, der ender forkert, eller en sanktions-eksponering hos en modpart, der opdages for sent. Mekanikken er forskellig. Den operationelle sandhed er den samme.

Den rodede midte er produktet

De fleste teams behandler distribution og dispute handling som noget, man tager “efter launch”. Det er en fejl. I reguleret money movement er den rodede midte produktet. Den omfatter:

• Distribution controls: hvem der må onboarde, funding, redeem – og under hvilke betingelser.
• Customer support og klager: intake, triage, tidslinjer og audit trails.
• Exception handling: hvad der sker, når en transfer bliver forsinket, midler bliver frosset, eller en modpart bliver flagged.
• Dispute flows: chargeback-lignende tilbageførsler, delvise refunds, fejlrettede betalinger og “double-spend”-ækvivalenter i den virkelige verden.
• Loss allocation: hvem der betaler, når en fejl ikke kan rettes op.

Kunden er ligeglad med, om den underliggende rail er en stablecoin, et tokenized deposit eller en bankoverførsel. De går op i, at saldoen er korrekt og brugbar, at de kan få hjælp, og at nogen kan bringe systemet tilbage i en valid tilstand, når virkeligheden bryder din happy path.

Det er også hér, de fleste “innovationer” stille og roligt genintroducerer risiko. Tokenization fjerner ofte en velkendt reversal-mekanisme og erstatter den med “finality”. Finality er fantastisk til settlement. Den er elendig for customer experience, når du har fraud, fat-fingered adresser, kompromitterede konti eller merchant disputes. Hvis dit operating model ikke hurtigt kan genoprette fairness, så gør regulatoren det – og på den dyreste måde: ved at tvinge liability over på den part, der er lettest at føre tilsyn med.

Regulering bliver først virkelig, når SLA’en er eksplicit

Jeg lærte i industriel teknologi, at governance uden håndhævelige interfaces er teater. I mine år i power electronics blev kvalitetsproblemer aldrig løst ved at sige “vi går op i kvalitet”. De blev løst ved at definere kontrakten mellem engineering, produktion, leverandører og service: hvad der udgør en fejl, hvordan den rapporteres, hvem der ejer containment, hvem der ejer root cause, og hvor hurtigt corrective actions skal lande.

Finansiel regulering følger samme mønster – bare med penge i stedet for hardware. Hvis du vil vide, om et tokenized money-setup er robust, så bed om den operationelle kontrakt, ikke whitepaperet.

Som operatør og bestyrelsesmedlem ville jeg presse på for fem eksplicitte SLA’er på tværs af stakken:

1. Time to acknowledge: hvor hurtigt en brugerklage får et ticketnummer bekræftet af et menneske – ikke bare et auto-reply.
2. Time to freeze: hvor hurtigt du kan stoppe yderligere skade, når fraud mistænkes. Det er payments’ “stop button”.
3. Time to reconcile: hvor hurtigt du kan dokumentere, hvad der skete på tværs af ledger, bankkonti og intermediaries.
4. Time to provisional credit or denial: hvornår kunden midlertidigt stilles som før, eller hvornår du formelt afslår med begrundelse.
5. Time to final resolution: lukning med fuld audit trail og loss allocation.

Hvis du ikke kan skrive dem ned og sætte en owner på hver, så har du ikke et compliant system. Du har en demo.

Det er også derfor, jeg ofte siger til fintech-teams, at de bør studere industriel incident response. På et anlæg “venter man ikke og ser”, når temperaturen går uden for rammen. Man stopper linjen, isolerer problemet og starter først igen, når man kan bevise stabilitet. Money movement fortjener samme disciplin. Jeg skrev om den mental model i AI Value Isn’t in the Org Chart. It’s in the Stop Button. Princippet er identisk: autoriteten til at stoppe er en del af governance.

Ops liability: beslut det tidligt – ellers bliver det besluttet for dig

I cross-border set-ups er standardresultatet forudsigeligt: risiko skubbes ned ad bakke til det svageste led. Distributøren siger “issuer problem”. Issuer siger “wallet problem”. Wallet siger “user error”. Kunden siger “ikke mit problem”. Regulatoren siger “alle har ansvar” – og vælger derefter den enhed, den kan give bøder.

For at undgå det har du brug for en liability model, der er designet – ikke bare underforstået.

Jeg kan godt lide at rammesætte det som en enkel RACI plus balance sheet-realisme:

• Responsible: hvem der kører processen i hverdagen (teamet, der faktisk kan trække i håndtagene).
• Accountable: hvem der underskriver policy og hæfter, når den fejler (én enhed – ikke et udvalg).
• Consulted: hvem der bidrager med input (compliance, bankpartnere, chain analytics, fraud vendors).
• Informed: hvem der skal have visibility (bestyrelse, regulatorer, centrale distributionspartnere).

Og så to spørgsmål, de fleste teams undgår:

• Hvem har autoriteten til at reversere eller kompensere, når rail’en ikke understøtter reversal?
• Hvor absorberes tabet, når recovery er umulig – og hvordan finansieres den reserve?

Hvis du bygger stablecoin- eller tokenized money-distribution, bygger du reelt et lag af consumer protection. Du kan lade som om, du ikke gør – men du ender alligevel med arbejdet, når disputes rammer i skala.

I mit eget venture-arbejde ser jeg det her som en design-input, ikke compliance overhead. Med IBHQ, hvor workflows rører onboarding, risk checks og partner operations, er jeg allergisk over for “det håndterer nogen andre”-tankegang. I det øjeblik du skalerer, bliver “nogen andre” til “ingen”, og du ender med en backlog af exceptions, der nedbryder tillid.

Dispute control plane: byg det som et rigtigt system

Dispute plumbing lyder kedeligt, indtil man sætter tal på effekten. Det påvirker conversion, retention, supportomkostninger, fraud loss og regulatorisk risiko. Det er også dér, de fleste tokenized set-ups er svagest, fordi de underliggende rails ikke er bygget til consumer disputes.

Så byg en dispute control plane eksplicit. Praktisk betyder det:

1) En fælles event model på tværs af parter

Hvis din distributør, issuer og wallet provider hver har deres egne transaction identifiers, kommer du aldrig til at reconcile hurtigt. Du har brug for en fælles reference model, der binder sammen: bruger, funding source, on-chain tx, off-chain ledger entries, fees og settlement state.

Det minder om det, jeg så i manufacturing og connected devices: hvis service tickets ikke kan knyttes til en specifik hardware revision, firmware version og batch, har du ikke traceability. Payments er ikke anderledes. Traceability er fundamentet for resolution.

2) En tydelig eskalationsvej, der krydser virksomhedsgrænser

Når en incident krydser jurisdiktioner, skal eskalationen stadig være én hop. Ikke fem emails og et ugentligt call. Definér escalation ladder, on-call-struktur og decision rights. Hvis det ikke er testet, findes det ikke.

3) Foruddefinerede dispute-typer og playbooks

Behandl ikke hver sag som specialarbejde. Lav en taxonomy: unauthorized transfer, duplicate debit, forkert modtager, merchant dispute, sanctions-relateret freeze, teknisk outage, KYC mismatch osv. Hver type får en playbook, en data-checkliste og en target resolution time.

4) En “reversal equivalent”-mekanisme

On-chain finality fjerner ikke behovet for reversals. Det ændrer bare, hvordan du implementerer dem. Du skal have en policy og en mekanisme for customer restitution: interne ledger-justeringer, reserve-finansierede credits, clawback hvor det er juridisk og teknisk muligt, samt eksplicitte eligibility criteria.

Det er hér, mange teams forveksler technical architecture med operating architecture. Operating architecture er det, regulatorer og kunder kommer til at mærke.

5) Et målbart error budget

I industrielle operationer styrer man reliability med error budgets og containment. Brug samme disciplin på disputes. Fastlæg acceptable thresholds for fejlede settlements, reconciliation breaks, support response times og fraud loss. Bemænd og automatisér derefter, så I holder jer inden for de thresholds.

Det hænger sammen med, hvordan jeg tænker control planes i payments. Rail’en er ikke produktet. Control plane er. Hvis det resonerer, så udfolder A Debit Network Is Not a Network. It Is the Checkout Control Plane. den samme pointe fra en anden vinkel.

Det, jeg ville bede om i bestyrelseslokalet i dette kvartal

Hvis du er bestyrelsesmedlem eller operatør med ansvar for tokenized money- eller stablecoin-distribution ind i Europa, så start ikke med udstedelseslicensen. Start med operability.

• Vis mig dispute-kortet: alle parter, alle handoffs og hvor midler kan sætte sig fast.
• Vis mig liability-tabellen: for hver failure mode – hvem betaler, hvem beslutter, og hvilken dokumentation kræves.
• Vis mig SLA’erne: acknowledge, freeze, reconcile, provisional credit, final resolution.
• Vis mig stop button: hvem kan pause onboarding, pause redemptions eller stoppe en distributionskanal – og efter hvilke kriterier.
• Vis mig reconciliation truth: én canonical ledger, og hvordan den bindes til bankkonti og on-chain transaktioner.
• Vis mig, hvordan I træner partnere: for det svageste led bliver en tredjepart med et script og nul kontekst.

Hvis svarene er vage, er strategien ikke “tidlig”. Den er ufærdig.

Da jeg byggede og drev EatMore, en platform til ordering og loyalty i hospitality, vandt eller tabte vi på eksekveringsdetaljer, som ingen skrev på forsiden: refunds, charge disputes, manglende ordrer og evnen til at løse problemer hurtigt på tværs af merchants og brugere. Den erfaring gjorde mig stædig omkring operationelt ejerskab. I reguleret tokenized money er den stædighed ikke valgfri. Det er forretningen.

Markedet vil belønne den token, der føles kedelig i driften: forudsigelig, til at få fat i, reversibel når det er nødvendigt, og tydelig om, hvem der står med ansvaret.

Mit syn er klart: Hvis MiCA udvikler sig til at dække flere instrumenter og flere issuer footprints, bliver vinderne ikke de teams, der kan skrive det pæneste issuance memo. Det bliver de teams, der kan bevise – end to end – at disputes bliver løst inden for en defineret tidsramme, med en defineret owner og en defineret loss model. Sådan ser tillid ud i praksis.

Alt andet er bare at flytte risiko rundt i stakken, indtil den lander hos kunden.