Styrings- og revisjonshull som dreper tokeniseringsprosjekter

Prosjekter for tokenisering av bedrifter kan møte problemer når de settes ut i livet, selv om blokkjededelen fungerer som den skal. En smart kontrakt kan utføre transaksjoner riktig, tokens kan opprettes uten problemer, og systemet kan bestå sikkerhetstester. Prosjektet kan fortsatt ha problemer med å få intern godkjenning for å oppfylle revisjonsregler, slik at eierskapsregistreringene er korrekte eller at investorreglene alltid følges.

For folk som tar avgjørelser i et selskap er dette en viktig forskjell. Tokenisering handler ikke om å gjøre en eiendel om til en digital versjon. Det legger til en teknologidel som må samsvare med rettigheter, økonomiske poster, hvordan ting drives og reglene som gjelder. Når disse delene håndteres separat, oppstår det ofte problemer når prosjektet tas i bruk, når folk sjekker det, eller når det gjøres større enn testen.

En robust tilnærming til styring av tokenisering i bedrifter bringer alle disse oppgavene inn i systemet når det bygges. Den bestemmer hvem som kan godkjenne handlinger, hvordan eierskap kontrolleres, hvilke regler som gjelder for flytting av tokens og hvilket bevis som trengs når et valg vurderes.

Målet er ikke å legge til trinn for å gjøre ting. Det er å lage et system som selskapet kan bruke, overvåke, forklare og forsvare mens eiendelen brukes.

Hvorfor mislykkes Enterprise-tokeniseringsprosjekter når de kontrolleres for styring?

Enterprise tokenization-prosjekter har ofte problemer med styring når teknologidelen beveger seg raskere enn måten selskapet trenger å jobbe med den. Ingeniører kan fokusere på kontrakter, hvordan man bruker lommebøker og hvordan man utfører transaksjoner mens juridiske samsvars-, finans- og driftsteam jobber med forskjellige dokumenter og trinn for å få godkjenning.

Denne splittelsen skaper et mellomrom mellom hva systemet kan gjøre og hva selskapet har lov til å gjøre.

Tenk deg en eiendomsplattform. Smartkontrakten kan håndtere flytting av tokens. Selskapet må også opprette rettighetene disse tokenene representerer, betingelsene for når eierskap kan endres og postene som viser disse endringene. Hvis måten systemet flytter tokens på ikke samsvarer med reglene, kan en transaksjon som fungerer teknisk sett fortsatt forårsake problemer med poster eller regler.

Det samme problemet skjer med penger, lån, obligasjoner, varer og andre ting som gjøres om til tokens. Reglene for hver ting endres basert på typen ting og hvor den er, men hovedbehovet er det samme: måten ting gjøres på må samsvare med det selskapet har lov til å gjøre. Hvilke regler gjelder?

Det er her samsvar med tokenisering blir en del av systemdesignet, ikke en siste kontroll. Reglene for å være i samsvar med loven må forme hvem som kan gjøre ting, hvordan regler anvendes, hvordan man rapporterer og hvilke bevis som oppbevares før systemet begynner å fungere ordentlig.

En sjekk av styring bør se utover kodens kvalitet. Den bør sjekke om systemet beholder rettighetene til eiendelene, følger de tillatte reglene, fører oversikt over valg og hjelper folk med å sjekke at systemene fungerer.

7 måter styringsproblemer kan forårsake problemer for tokeniseringsprosjekter for bedrifter

Problemer med styring stammer vanligvis ikke fra én feil. De er mer sannsynlig å oppstå når ansvar, kontroller og registreringer ikke er samordnet gjennom hele eiendelens livssyklus. Følgende problemer må tas i betraktning før systemet tas i bruk på alvor.

1. Uklar eierskap til eiendeler og utsteders ansvar

Det at man oppretter tokens i seg selv betyr ikke at det underliggende aktivumet er lovlig flyttet, eller at personene som eier tokenene har rettighetene som er beskrevet i dokumentene som forklarer salget av dem. Reglene må si om et token er for å eie noe til fordel for et lån, en del av et fond eller for en annen avtale.

Uten denne forståelsen kan det bli krangler om betalinger, stemmer, å få tilbake pengene eller om det er tillatt å flytte tokenene. Personen som opprettet tokenene må også bestemme hvem som er ansvarlig for å sjekke tingen, ha papirene, fortelle folk om den og holde seg oppdatert på rapporter.

En ideell styringsmodell knytter hvert tokenisert aktivum til papirene som forklarer det, personen som opprettet det, registreringer av hvem som eier det og de klare rettighetene til personene som har tokenene. Endringer i tingen eller dens regler må gjennomgå en papirkontroll og få godkjenning før de skjer.

2. Svake identitets-, tilgangs- og tillatelseskontroller

Et system kan ha måter folk kan gjøre ting på, men det er ikke tydelig på hvem som kan starte, godkjenne og utføre viktige operasjoner. Dette gjør det enkelt for folk å gjøre ting uten tillatelse, endre reglene for flytting av tokens eller få tilgang til informasjon de ikke burde se.

For at styring av tokenisering i bedrifter skal være effektiv, må tilgangspolicyer gjenspeile det faktiske organisasjonsansvaret. Å lage tokens, endre hvordan systemet fungerer, få tilbake i en lommebok, endre reglene og håndtere pengene, må ha klare regler. Store endringer kan kreve at mer enn én person sier ja, avhengig av hvor risikable de er.

Tilgangsgjennomganger bør også ta hensyn til avganger av ansatte, rolleendringer, tredjepartsadministratorer og kompromitterte legitimasjonsdetaljer. Målet er å sørge for at alt som kan gjøres med fullmakt er tillatt.

3. Ufullstendige revisjonsspor for smarte kontrakter

En smartkontrakt kan vise at en transaksjon har funnet sted, men forteller kanskje ikke historien bak den. En revisor kan se at en bevegelse har funnet sted, men trenger fortsatt å vite hvem som sa at det var greit hvis de riktige reglene ble fulgt, og hvilken versjon av reglene som ble brukt.

Dette er viktig når folk endrer reglene, stopper trekk, oppdaterer systemet eller retter feil. Hvis systemet ikke holder oversikt over disse valgene og bevisene som følger med dem, kan det være vanskelig å finne ut hva som skjedde.

Effektiv samsvar med regelverket for tokenisering krever mer enn bare registreringer av hva som skjedde på blokkjeden. De må holde oversikt over hva folk som sa ja gjorde, historikken til reglene, logger over ting og lenker til dokumenter som ikke finnes på blokkjeden. Privat eller finansiell informasjon bør beskyttes med tilgangs- og lagringsregler i stedet for å bli skrevet inn i et offentlig register.

4. Mangler i håndheving av KYC, AML og investorberettigelse 

Å sjekke hvem som eier tokenene i starten betyr ikke at de vil bli værende på stedet hele tiden tokenene brukes. Regler for hvem som kan ha tokenene kan avhenge av typen person, hvor de er, tilbudets regler og hvor mye de kan holde, eller om situasjonen deres endrer seg.

Hvis disse reglene er i den delen der folk først blir med, kan det hende at systemet ikke alltid bruker dem. En token kan gå til en lommebok som ikke fullførte kontrollene eller ikke har tillatelse til å ha den typen token.

Regler bør knytte sammen kontroll av identiteten til personene som sjekker om de er på en liste over personer som ikke skal gjøre forretninger, med kontroll av om de har lov til å ha tokenreglene om flytting av tokener og kontroll hele tiden. Systemet bør også si hva man skal gjøre hvis papirene ikke er oppdaterte, hvis en flytting ikke er tillatt, hvis en overføring blir stilt spørsmål ved, eller hvis det er et problem med reglene.

Reglene som trengs bør avgjøres av hvor tokenet er og hvor det er. En metode som fungerer for ett tilbud, er kanskje ikke bra for et annet.

5. Manglende avstemming på og utenfor kjeden

Mengden tokens og bevegelsene på blokkjeden er ikke alle dokumentene som trengs. Bedrifter kan også ha papirer for hvem som eier tingen, registre over hvem som har den, kontoutskrifter, dokumenter om pengeavtaler om innmelding og registre over penger som gis ut.

Når disse systemene ikke fungerer sammen, kan det oppstå problemer. En bevegelse på blokkjeden kan bli registrert uten at et dokument om den endres. En betaling kan bli foretatt av et pengesystem uten at tokensystemet blir varslet. Ingen av situasjonene kan løses ved å gjette.

En måte å sjekke at de ulike delene samsvarer på, bør si hvilken som er den riktige for hver del av papirene, hvor ofte kontrollene gjøres og hvordan man skal fikse problemer når de oppstår. Problemer bør forbli synlige inntil noen med rett til å gjøre det kan fikse dem med bevis.

6. Uklare prosedyrer for oppgradering, gjenoppretting og hendelsesrespons

Systemer som håndterer tokens trenger tiltak når ting går galt, som hvis noens tilgang blir stjålet, hvis det er en feil i koden, hvis et trekk ikke er riktig, hvis systemet ikke kan brukes, eller hvis måten systemet fungerer på ikke er forventet. Bare å være sikker er ikke nok hvis selskapet ikke kan gjøre noe når reglene slutter å fungere.

Reglene for styring bør si hvem som kan stoppe ting, hvem som kan endre systemet, hvem som kan komme inn igjen og hvem som kan fikse problemer. De bør også si hvordan man skriver ned valgene som er tatt og forteller andre om dem.

Måten å fikse ting på bør også tenke på hva som skjer operasjonelt når endringer gjøres. Det er kanskje ikke mulig å angre et trekk som ble gjort på blokkjeden, og enhver rettelse må følge reglene for tokenet og loven.

7. Utilstrekkelig bevis for interne og eksterne revisjoner

Det er vanskelig å forberede seg på sjekker når bevisene finnes på steder som e-post, regneark, separate systemer og forskjellige team. Selv om det finnes regler på plass, kan ikke selskapet bevise at de ble brukt på den måten.

For å være forberedt på en sjekk må man ha en måte å få tak i, beskytte og finne beviset på. Dette inkluderer godkjenninger for regler som sjekker hvem som har tilgang, valg om hvem som kan ha token-sjekker på tingene som eies, endringer i regelproblemer som oppstår og løsninger på dem.

Måten beviset oppbevares på bør angi hvor lenge det oppbevares, hvem som kan se det, hvem som har ansvaret for det og hvordan hver regel er knyttet til dokumentene som beviser det. Det bør også la folk sjekke det uten å se ting de ikke burde se.

En plattform designet av et erfarent selskap for utvikling av tokeniseringsprosjekter for bedrifter bør imøtekomme disse kravene som en del av implementeringsomfanget, i stedet for å behandle dem som dokumentasjon som skal samles rett før en revisjon.

Hvorfor smarte kontraktsrevisjoner alene ikke kan sikre samsvar med tokenisering

Å sjekke koden er en viktig måte å sikre at systemet er trygt, men det løser bare deler av problemet med et selskaps tokeniseringsprosjekt. Den ser vanligvis på koden for feil, uventet oppførsel og svake deler. Den sjekker ikke automatisk om reglene som følger med tokenet er riktige, om papirene utenfor systemet er riktige, eller om selskapets trinn for å få godkjenning fungerer.

En kontrakt kan gjøre det den er bedt om å gjøre, men den kan følge en regel som ikke er fullstendig eller feil. For eksempel kan en måte å flytte tokens på fungere uten feil. Reglene som følger med den kan trenge flere kontroller for hvem som kan ha tokenet. En kontrakt kan også gi ut tokens riktig. Dokumentene som forklarer hva tokenet er, er kanskje ikke riktige.

Dette skillet har praktiske implikasjoner for samsvarsløsninger for tokenisering . Sikkerhetstesting bør suppleres med kontrollvalidering, juridisk gjennomgang, avstemmingstesting, tilgangsvurderinger og testing av driftsscenarier.

Sjekken bør sørge for at det systemet gjør er det selskapet sier det skal gjøre. Testene bør dekke både bevegelser og uvanlige situasjoner, som bevegelser som feiler personer som ikke har lov til å ha en token, personer som endrer regeloppdateringer i systemet og problemer mellom postene på blokkjeden og papirene i selskapet.

En uavhengig revisjon kan hjelpe mye. Den kan ikke erstatte selskapet med å sørge for at reglene er på plass. Ansvaret for reglene slik de er. Hvem som har ansvaret må være tydelig.

Hva bør et rammeverk for styring av bedriftstokenisering inkludere?

Et effektivt rammeverk kobler forretningsansvar med teknisk håndheving og verifiserbar bevis. I stedet for å behandle styring som et enkelt policydokument, bør bedrifter etablere et koordinert sett med kontroller på tvers av plattformen og organisasjonen som driver den. 

For selskaper som vurderer hvordan de skal håndtere tokenisering, bør systemet være riktig for risikoen knyttet til eiendelen, hvordan transaksjoner fungerer, hvem som er involvert og hvilke regler som gjelder. En privat investering som ikke lett kan flyttes, kan trenge mer kontroll enn et system som håndterer mange typer eiendeler og handel etter det første salget.

Styring må også endres etter hvert som systemet endres. Nye typer eiendeler involverer oppdaterte kontraktsvilkår, og samarbeid med andre selskaper kan føre til risikoer som ikke var der da det først startet.

Hvordan kan bedrifter identifisere styringshull før lansering?

En strukturert vurdering før lansering hjelper bedrifter med å finne løsninger før de koster mye. Den bør inkludere personer som har ansvaret for ressursen, teknologien, det juridiske oppsettet, samsvar med regler, økonomien og driften av systemet.

Følgende liste gir et sted å begynne.

• Bekreft at tokenrettighetene samsvarer med de styrende juridiske dokumentene.
• Tildel eiere for utstedelse, overføringer, oppgraderinger, gjenoppretting og rapportering.
• Testidentitetsverifisering og begrensninger for investorers kvalifisering.
• Valider administratortillatelser og godkjenningsseparasjon.
• Avstem tokensaldoer med autoritative eiendels- og økonomiske poster.
• Dokumenter endringer i smarte kontrakter og administrative inngrep.
• Test hendelsesrespons, forretningskontinuitet og gjenopprettingsprosedyrer.
• Bekreft at revisjonsbevis kan innhentes av autoriserte kontrollører.
• Gjennomgå avhengigheter hos tredjeparter og definer deres ansvar.
• Innhent dokumentert godkjenning fra relevante forretnings- og kontrolleiere.

Organisasjoner som engasjerer et selskap for utvikling av prosjekter innen enterprise tokenization, bør også etablere akseptkriterier for styring før utviklingen starter. Dette sikrer at teamet vet hvilke kontroller som må på plass, hvilke systemer som må fungere og hvilke bevis som trengs for å gå live.

En kontroll av styringen er best når det skjer nok til å endre hvordan systemet er bygget opp. Å legge til tilgangsregler som endrer rapportering eller fikse dataproblemer etter at det er satt i drift kan gjøre at ting tar lengre tid enn nødvendig.

Gjør styring til en del av tokenisering fra starten av

Styring fungerer best når det er en del av prosjektet før de første pengene tjenes. Regler om kontroll av eiendeler, hvem som kan bli med, godkjenninger, kontroll av antall og bevis for revisjoner bør gjøres tydelige i de løpende planene i de tidlige trinnene.

Dette krever at folk fra deler av selskapet jobber sammen. Hver gruppe bør vite hvilke valg de tar, hvilke regler systemet må følge og hvordan de skal håndtere unntak. Arbeidet bør omfatte å sjekke kontrollene på det tidspunktet, samt å sjekke funksjoner og sikkerhet med klare regler som må overholdes før lansering.

Ideelle løsninger for samsvar med tokenisering bør hjelpe med denne måten å jobbe på uten å gjøre ting for vanskelige. Avhengig av hva som trengs, kan det bety regler som stopper visse bevegelser, administrere hvem som kan gjøre hva, føre oversikt over handlinger som knytter seg til personer som sjekker identiteter, måter å sjekke tall og tømme rapporter på.

Bedrifter bør også tenke på hvordan disse reglene vil endres etter hvert som systemet vokser til steder eller typer eiendeler. En forvaltningsmåte som fungerer for én type investering kan trenge regler, flere måter å rapportere på eller flere juridiske kontroller når virksomheten legger til noe nytt.

Målet er å gjøre styring til en vanlig del av hvordan selskapet fungerer, ikke noe som bare skjer før oppstart.

Hvordan Antier hjelper med Enterprise Tokenization-prosjekter

Antier ser på enterprise tokenization som en blanding av hvordan aktivumet er satt opp, hvordan blokkjeden fungerer, hvordan systemet kjører og reglene som må følges. Arbeidet deres inkluderer å lage systemer for eiendom, fond, varer og andre virkelige ting med design som matcher hvert prosjekt.

Som et prosjektutviklingsselskap for tokenisering i bedrifter, hjelper Antier med å lage tokens, kontrollerte overføringer, smarte kontrakter, hvordan få folk til å bli med, hvordan administrere hvem som gjør hva og hvordan koble seg sammen for å administrere levetiden til aktiva. Det nøyaktige arbeidet avhenger av hva slags aktiva det er snakk om, hvordan det fungerer og hva kunden ønsker.

Målet er å matche det systemet kan gjøre med reglene og kontrollmulighetene som ble satt i planleggingen. Juridiske svar, regler og kontroller fra andre er fortsatt jobben til menneskene og gruppene.

Bedrifter som ser på et tokeniseringsprosjekt kan starte med å finne problemene sine med regler som sier hvilke kontroller som trengs, og se hvordan disse skal vises i systemdesignet.