Fintech Uutiset
Ohjelmoitavat maksut: säännöt, API-rajapinnat ja älykkäät sopimukset
Mitä ohjelmoitavat maksut todella ovat, miten ehdolliset ohjeet eroavat ohjelmoitavasta rahasta, ja missä API:t, älykkäät sopimukset, orakelit ja atominen selvitys sijoittuvat.
Lisää Securities.io suosikkilähteisiisi Google-palvelussa
Kuvittele lasku, joka tulisi maksaa vasta kun tavarat ovat saapuneet, anturi vahvistaa, että lämpötila on pysynyt sallitulla alueella, ja molemmat yritykset hyväksyvät lopullisen määrän. Ohjelmoitava maksu voi koordinoida nämä ehdot. Se ei kuitenkaan voi taikavoimilla päättää, onko anturi luotettava tai onko oikeudellinen sopimus täytetty.
Ohjelmoitavuus siirtää liiketoimintasäännöt lähemmäs rahansiirtoa. Arvokasta ei ole koodin uutuus, vaan kyky tehdä ehdot selkeiksi, testattaviksi ja kytkeä ne rajoitettuun maksuvallan tahoon.
Ohjelmoitava maksu on siirto, jonka aloitus, määrä, ajoitus tai kohde määritellään koneellisesti suoritettavilla säännöillä. Sääntö voi olla tavallisessa sovellusohjelmistossa, pankin työnkulkujärjestelmässä tai älykkäässä sopimuksessa. Ohjelmoitavuus ei siis ole sama asia kuin lohkoketju. Oleellista on, että määritellyt ehdot arvioidaan ja valtuutettu järjestelmä saa rahan liikkumaan.
Ohjelmoitavat maksut eivät välttämättä ole ohjelmoitavaa rahaa. Perinteistä pankkitalletusta voidaan siirtää ohjelmistosääntöjen avulla, vaikka raha säilyttääkin tavalliset ominaisuutensa. Ohjelmoitava raha sisällyttäisi tai pakottaisi ehdot rahainstrumentin tai kirjanpitoverkon tasolle. Tämän eron säilyttäminen estää automaatiotoiminnon sekoittumisen uuteen rahamuotoon.
Ohjelmoitavat maksut yhdellä katsauksella
Prosessi alkaa valtuutuksella, muuntaa sen deterministisiksi ehdoiksi, kerää luotettavat syötteet, arvioi säännön, lähettää maksun valtuutetun kanavan kautta ja kirjaa tuloksen. Älykkäässä sopimuksessa voi olla useita vaiheita, mutta se on silti riippuvainen henkilöllisyyksistä, tietolähteistä, omaisuudesta ja koodin ulkopuolisista oikeudellisista sopimuksista.
Kuka tekee mitä ohjelmoitetuissa maksuissa?
| Säännön luoja | Ilmaisee kaupallisen ehdon ja määrittelee, kuka voi muokata tai peruuttaa sen. |
|---|---|
| Tietolähde tai orakeli | Tarjoaa ulkoisen tosiasian, jonka varaan suoritus riippuu. |
| Suoritusmoottori | Arvioi ehdot deterministisesti ja lähettää valtuutetut ohjeet. |
| Rahan ja omaisuuden kirjanpito | Säilyttää vaateita, joiden omistus tai saldot muuttuvat. |
| Hallintokerros | Käsittelee henkilöllisyyden, riidat, päivitykset, hätätilanteet ja oikeudellisen täytäntöönpanokyvyn. |
Maksaja määrittelee valtuutuksen; ohjelmisto arvioi ehdot; orakeli tai API toimittaa tosiasiat; pankki, stablecoinin liikkeeseenlaskija tai kirjanpito siirtää omaisuuden; ja operaattori käsittelee poikkeukset. Oppaamme älykkäisiin sopimuksiin selittää koodikerroksen, kun taas Paxos selitettynä näyttää, miksi selvitysomaisuus ja sen liikkeeseenlaskija pysyvät erillisinä.
Hyödyllinen tapa arvioida ohjelmoituja maksuja on aloittaa lopusta eikä alusta. Kysy, mitä vastaanottaja, sijoittaja tai instituutio voi lopulta vaatia tuloksen kirjaus jälkeen, ja seuraa sitten tulosta takaisin vahvistus kautta säännön määrittäminen hyväksyttyyn todistukseen. Jokaisen siirtymän tulisi nimetä muuttunut tietue, sen hyväksyvä valtuutus ja ehto, joka tekisi siirtymän pätemättömäksi. Jos polku päättyy hallintapaneelin viestiin tai toimittajan tilaan, järjestelmä on kuvannut käyttöliittymätapahtuman – ei välttämättä täytäntöönpanokelpoinen tulos.
Vastuun kartta on tärkeä samasta syystä. Säännön luoja ja hallintokerros voivat molemmat osallistua samaan asiakaspolkuun, mutta ne eivät lupaa samaa eikä ylläpidä samaa todistusaineistoa. Kun yritys ulkoistaa toiminnon, operatiivinen tehtävä voi siirtyä, kun taas oikeudellinen velvoite, asiakassuhde tai menetyksen absorboimisen velvoite pysyy paikallaan. Siksi perusteellinen tarkastelu tulisi kysyä, kuka voi korjata valtuutetun tietueen, kuka rahoittaa poikkeuksen ja mikä osapuoli jatkaa toimintaansa, jos toimittaja epäonnistuu pahimmassa mahdollisessa hetkessä.
Lopuksi testaa kaksi epäonnistumista yhdessä sen sijaan, että testaisit ne yksi kerrallaan: virheellinen määrittely yhdessä peruuttamattomuus. Todelliset tapaukset harvoin noudattavat prosessikaavion siistejä rajoja. Kontrolli on uskottava vain, jos osallistujat voivat säilyttää oikean vaatimuksen, rekonstruoida sekvenssin, viestiä viiveen ja saavuttaa yhden sovitetun tilan ilman, että he keksivät toisen version tapahtumasta. Tämä testi muuttaa Ohjelmoitavat maksut markkinointitermistä järjestelmäksi, jota voidaan tarkastella.
Missä Ohjelmoitavien maksujen tiedot on sovittava
Sääntö voi toteutua oikein virheellistä syötettä vastaan. Tämä tuottaa teknisesti kelvollisen, mutta taloudellisesti virheellisen tuloksen. Auditointijäljen on siis yhdistettävä alkuperäinen toimeksianto, datan alkuperä, sääntöversio, valtuutus, tapahtuman tunniste ja lopullinen kirjanpitotila.
Kuinka Ohjelmoitavat maksut toimivat
1. Määritä sääntö Ohjelmoitavissa maksuissa
Säännön on oltava tarkempi kuin liiketoimintalause. ‘Maksa, kun tavarat saapuvat’ vaatii määritelmiä tavaroille, kohteelle, tarkastukselle, ajalle, osittaiselle toimitukselle ja riita-asioille. Koodi voi suorittaa vain saamansa tilan. Epäselvyys ei katoa; se siirtyy datamäärittelyihin ja hallintoon.
2. Havaitse tapahtuma Ohjelmoitavissa maksuissa
API‑käynnistetty työnkulku voi kysyä logistiikkapalvelulta ja lähettää pankkimaksun hyväksynnän jälkeen. Älykkäät sopimukset voivat pitää tokenisoitua omaisuutta tai ohjetta ja toteuttaa sen, kun lohkoketjussa olevat ehdot täyttyvät. Arkkitehtuurit eroavat luottamuksessa ja selvityksessä, mutta molemmat tarvitsevat todennetut tiedot ja rajatun valtuutuksen.
3. Vahvista Ohjelmoitavissa maksuissa
Oracle‑ongelma syntyy, kun digitaalinen sääntö riippuu fyysisestä maailmasta. Anturi voi epäonnistua; datan tarjoajaa voidaan manipuloida; useat lähteet voivat olla ristiriidassa. Kestävät suunnitelmat määrittelevät lähteiden hierarkian, toleranssit, haasteaikavälit ja turvallisen tilan sen sijaan, että oletetaan datan olevan totuus.
4. Suorita atomisesti Ohjelmoitavissa maksuissa
Atominen selvitys linkittää muutokset siten, että joko kaikki tapahtuvat tai ei mikään. Toimitus‑vastaan‑maksu on klassinen esimerkki: omaisuus siirtyy vain, jos maksua siirretään. Atomisuus voi vähentää pääomariskin, mutta se voi lisätä likviditeettitarvetta, koska jokainen vaadittu omaisuus on oltava saatavilla samanaikaisesti.
5. Tallenna tulos Ohjelmoitavissa maksuissa
Kontrollit tulisi sijoittaa sekä säännön ulkopuolelle että sisälle. Henkilöllisyys, pakotteet, kulutusrajat, hätäkeskeytykset ja päivitysmenettelyt ovat hallintotoimintoja. Itsesuorittava sopimus ilman laillista poikkeusprosessia voi automatisoida väärän tuloksen tehokkaammin.
Ohjelmoitavien maksujen talous
Ohjelmoitavuus vähentää koordinointia ja sovittelua, kun useat toimet jakavat yhden tarkistettavan ehdon. Escrow, toimitusketjun rahoitus, rojaltit, vakuusvaatimukset ja käyttöperusteinen laskutus voivat kaikki hyötyä.
Säästöt ovat suurimmat, kun nykyinen prosessi sisältää toistuvaa viestintää, manuaalisia todisteita ja epävarmoja siirtoja. Jos alkuperäinen prosessi on jo yksinkertainen suoraveloitus, monimutkaisen lohkoketjun lisääminen voi nostaa kustannuksia.
Yhdistettävyys mahdollistaa sääntöjen liittämisen, mutta riippuvuus kasvaa jokaisen ulkoisen sopimuksen ja tietolähteen myötä. Taloudellinen tehokkuus on mitattava suhteessa ohjelmistoon, oracle‑ ja hallintoriskeihin.
Epäonnistumistilat Ohjelmoitavissa maksuissa
- Huono määrittely: Koodi voi uskollisesti suorittaa säännön, joka ei vastaa kaupallista sopimusta.
- Orakelin epäonnistuminen: Laukaisuaineisto voi olla virheellinen, vanhentunut, ei saatavilla tai strategisesti manipuloitu.
- Palautumattomuus: Automaattinen lopullinen selvitys voi jättää vähän aikaa petoksen estämiseen tai syötteen virheiden korjaamiseen.
- Yhdistettävyys: Yhden kytketyn sopimuksen epäonnistuminen voi levitä muuten kunnollisiin tapahtumiin.
- Valtuutus: On oltava selkeää, kuka voi keskeyttää, päivittää, kiistää tai ohittaa mekanismin.
Toimiva ohjelmoitavien maksujen esimerkki
Harkitse laitevuokrausta, jonka hinta perustuu vahvistettuun koneen käyttöön. Anturi raportoi käyttöajat; ohjelmisto vahvistaa laitteen ja vertaa käyttöä sopimukseen; maksajan tili valtuuttaa ennalta määritetyn maksurajan; ja maksutoimeksianto vapautetaan kuukausittain. Integroitu tokenisoitu järjestelmä voisi päivittää vuokrasaatavan ja maksun samanaikaisesti. Kummassakin mallissa vaikeat kysymykset ovat samat: kuka todistaa anturin, mitä tapahtuu, jos se on offline-tilassa, voiko asiakas haastaa mittauksen ja mikä kirjanpito todistaa lopullisen maksun?
Ohjelmoitavien maksujen taustalla oleva näyttö
BIS tokenisaation jatkumo ja sen tulevan rahajärjestelmän suunnitelma selittävät, miten yhteiset kirjanpidot ja ohjelmoitavuus voivat yhdistää viestinnän, omaisuuden ja selvityksen. Ne myös tekevät selväksi, että institutionaaliset ja hallintokerrokset pysyvät.
Federal Reserve -viraston julkaisu jakautunut kirjanpitoteknologia maksujen, selvityksen ja maksujen loppusijoituksen yhteydessä on hyödyllinen vastapaino puhtaalle koodikerronnalle, koska se asettaa sekä mahdollisuudet että operatiiviset haasteet kehyksiin.
Mitä muuttuu ohjelmoitavissa maksuissa?
BIS kuvaa tokenisoinnin yhdistävän tietoa omaisuudesta ja omistuksesta alustan sääntöjen ja hallinnon kanssa. Yhtenäiskirjanpito-tutkimus tutkii tokenisoidun keskuspankkiraahan, kaupallisen pankkiraahan ja omaisuuden sijoittamista yhteiseen ohjelmoitavaan ympäristöön. Lähitulevaisuudessa API:t ja request-to-pay -palvelut tekevät perinteisistä talletuksista ehdollisempia ja automatisoituja. Tulevaisuus on todennäköisesti hybridi: säännelty raha, ohjelmoitavat työnkulut ja valikoidut jaetut kirjanpidot, jotka on yhdistetty eksplisiittisillä ohjausmekanismeilla.
Kysymyksiä, jotka kannattaa esittää ohjelmoitavista maksuista
- Vaiheessa define rule, mikä tallenne osoittaa, että osapuolet määrittelevät ehdon, valtuutuksen, määrän, kohteen ja vanhentumisen.
- Vaiheessa observe event, mikä tallenne osoittaa, että luotettavat tiedot näyttävät, onko ehto toteutunut.
- Vaiheessa validate, mikä tallenne osoittaa, että ohjelmisto tarkistaa henkilöllisyyden, oikeudet, varat, politiikan ja säännön tilan.
- Vaiheessa execute atomically, mikä tallenne osoittaa, että maksu ja siihen liittyvä omaisuus tai tietue päivittyvät samanaikaisesti tai ei lainkaan.
- Vaiheessa record outcome, mikä tallenne osoittaa, että järjestelmä säilyttää todisteet, tilan, poikkeukset ja mahdolliset jäljelle jäävät velvoitteet.
Mitä lukea ohjelmoitavien maksujen jälkeen
Jotta näet, mihin tämä on menossa, lue Miten tokenisointi ja agenttipohjainen maksaminen muuttavat maksut. Perustavaa laatua olevalle omaisuusluokittelulle, jatka lukemalla Digitaaliset omaisuudet selitettynä.
Ohjelmoitavien maksujen yhteenveto
Ohjelmoitava raha on hyödyllisintä, kun se rajoittaa harkintavaltaa ja tuottaa parempaa näyttöä. Jos tietolähde, ohitusvaltuutus tai palautumispolku on epäselvä, automaatio tekee virheen nopeammin sen sijaan, että maksusta tulisi älykkäämpi.
Lähteet ohjelmoitaville maksuille
