Programmable Payments: Mga Patakaran, API, at Smart Contracts

Isipin ang isang invoice na dapat bayaran lamang matapos dumating ang mga kalakal, isang sensor na nagpapatunay na nanatiling nasa saklaw ang temperatura, at parehong kumpanyang nag-apruba sa huling dami. Ang isang programmable payment ay maaaring mag-ugnay sa mga kundisyong iyon. Hindi nito kayang magpasya, sa pamamagitan ng mahika, kung tapat ang sensor o natupad ang legal na kontrata.

Ang programmability ay nagdadala ng mga patakaran sa negosyo nang mas malapit sa paggalaw ng pera. Ang mahalagang bahagi ay hindi ang pagiging bago ng code; kundi ang kakayahang gawing malinaw, nasusubukan, at konektado sa awtoridad ng pagbabayad na nananatiling may hangganan.

Ang programmable payment ay isang paglilipat kung saan ang pagsisimula, halaga, oras, o destinasyon ay pinamamahalaan ng mga patakarang maaaring patakbuhin ng makina. Ang patakaran ay maaaring nakapaloob sa karaniwang application software, workflow engine ng bangko, o isang smart contract. Kaya’t ang programmability ay hindi katumbas ng blockchain. Ang mahalaga ay nasusuri ang mga tinukoy na kundisyon at isang awtorisadong sistema ang nag-uudyok sa paggalaw ng pera.

Ang programmable payments ay hindi awtomatikong programmable money. Ang isang karaniwang deposito sa bangko ay maaaring ilipat gamit ang mga patakaran ng software habang ang pera mismo ay nagpapanatili ng mga karaniwang katangian. Ang programmable money ay mag-i-embed o magpapatupad ng mga kundisyon sa antas ng instrumento ng pera o ledger. Ang pagpapanatili ng pagkakaibang ito ay pumipigil sa isang tampok ng awtomasyon na mapagkamalang bagong anyo ng pera.

Programmable Payments sa Isang Tanaw

Nagsisimula ang proseso sa isang mandato, ginagawang deterministic na mga kundisyon ang mandatong iyon, nangongolekta ng mapagkakatiwalaang input, sinusuri ang patakaran, nagsusumite ng pagbabayad sa pamamagitan ng awtorisadong channel, at itinatala ang resulta. Maaaring magsagawa ng ilang hakbang ang isang smart contract, ngunit ito ay nakadepende pa rin sa mga pagkakakilanlan, pinagmumulan ng datos, asset, at legal na kasunduan na nasa labas ng code nito.

Sino ang Gumagawa ng Ano sa Programmable Payments?

Itinatakda ng nagbabayad ang awtoridad; sinusuri ng software ang mga kundisyon; ang isang oracle o API ay nagbibigay ng mga katotohanan; isang bangko, naglabas ng stablecoin, o ledger ang naglilipat ng asset; at ang isang operator ay humahawak ng mga eksepsyon. Ang aming gabay sa matalinong kontrata ay nagpapaliwanag ng layer ng code, habang ang Paliwanag tungkol sa Paxos ay nagpapakita kung bakit nananatiling hiwalay ang settlement asset at ang naglabas nito.

Isang kapaki-pakinabang na paraan upang suriin ang Programmable Payments ay magsimula sa huli kaysa sa simula. Tanungin kung ano ang maaaring huling i-claim ng tatanggap, mamumuhunan, o institusyon matapos ang itala ang resulta, pagkatapos ay subaybayan ang resulta pabalik sa pamamagitan ng tiyak hanggang sa ebidensyang tinanggap sa itakda ang patakaran. Dapat pangalanan ng bawat paglipat ang rekord na nagbago, ang awtoridad na nagpatibay nito, at ang kundisyon na magpapawalang-bisa sa paglipat. Kung nagtatapos ang bakas sa isang mensahe sa dashboard o katayuan ng vendor, inilarawan ng sistema ang isang pangyayari sa interface—hindi kinakailangang isang mapapatupad na resulta.

Mahalaga ang mapa ng responsibilidad para sa parehong dahilan. Maaaring parehong lumahok ang tagalikha ng patakaran at ang layer ng pamamahala sa isang paglalakbay ng customer, ngunit hindi nila ipinapangako ang parehong bagay o pinapanatili ang parehong ebidensya. Kapag nag-outsource ang isang kumpanya ng isang function, maaaring lumipat ang operasyonal na gawain habang ang legal na tungkulin, relasyon sa customer, o obligasyon na sagutin ang pagkawala ay nananatili. Kaya’t dapat itanong ng isang masusing pagsusuri kung sino ang maaaring itama ang awtoritibong rekord, sino ang magpopondo ng eksepsyon, at aling kalahok ang dapat magpatuloy na mag-operate kung ang isang vendor ay nabigong magbigay ng serbisyo sa pinakamasamang sandali.

Sa huli, subukan ang dalawang pagkabigo nang magkasama kaysa isa-isa: maling espesipikasyon kasabay ng hindi na mababago. Bihirang sumunod ang totoong insidente sa malinis na hangganan ng isang diagram ng proseso. Ang isang kontrol ay kapani-paniwala lamang kung ang mga kalahok ay maaaring mapanatili ang tamang pag-angkin, muling buuin ang pagkakasunod-sunod, ipabatid ang pagkaantala, at maabot ang isang pinagkasunduan na kalagayan nang hindi nilikha ang ikalawang bersyon ng transaksyon. Ang pagsubok na iyon ay nagiging dahilan upang ang Programmable Payments ay lumipat mula sa isang label sa marketing tungo sa isang sistemang maaaring suriin.

Kung Saan Dapat Magkasundo ang mga Rekord ng Programmable Payments

Maaaring maisakatuparan nang tama ang isang patakaran laban sa maling input. Nagbubunga ito ng teknikal na wastong ngunit ekonomikong maling resulta. Kaya’t dapat ikonekta ng audit trail ang orihinal na mandato, pinagmulan ng datos, bersyon ng patakaran, awtorisasyon, identifier ng transaksyon, at huling kalagayan ng ledger.

Paano Gumagana ang Programmable Payments

1. Tukuyin ang Patakaran sa Programmable Payments

Dapat mas tiyak ang patakaran kaysa sa pangungusap ng negosyo. Ang ‘Magbayad kapag dumating ang mga kalakal’ ay nangangailangan ng mga depinisyon para sa mga kalakal, destinasyon, inspeksyon, oras, bahagyang paghahatid at pagtatalo. Maaaring isakatuparan ng code lamang ang kalagayang natanggap nito. Hindi nawawala ang kalabuan; ito ay lumilipat sa mga depinisyon ng datos at pamamahala.

2. Obserbahan ang Pangyayari sa Programmable Payments

Maaaring mag-query ang isang workflow na pinapagana ng API sa isang serbisyong logistika at magpadala ng bayad sa bangko pagkatapos ng pag-apruba. Maaaring humawak ang isang smart contract ng tokenized na asset o tagubilin at magsagawa kapag natugunan ang mga kundisyon sa ledger. Magkaiba ang mga arkitektura sa tiwala at pag-aayos, ngunit pareho silang nangangailangan ng pinatunayan na datos at limitadong awtoridad.

3. Patunayan sa Programmable Payments

Lumilitaw ang problema ng oracle kapag ang digital na patakaran ay nakadepende sa pisikal na mundo. Maaaring mabigo ang sensor; maaaring manipulahin ang tagapagbigay ng datos; maaaring magkasalungat ang maraming pinagmulan. Ang matibay na disenyo ay nagtatakda ng hierarchy ng pinagmulan, toleransya, mga panahon ng hamon, at isang ligtas na kalagayan sa halip na ipalagay na ang datos ay katotohanan.

4. Isakatuparan nang Sabay sa Programmable Payments

Ang atomic settlement ay nag-uugnay ng mga pagbabago upang mangyari ang lahat o wala. Ang delivery-versus-payment ay ang klasikong halimbawa: lumilipat lamang ang asset kung lumilipat ang bayad. Maaaring bawasan ng atomicity ang panganib ng prinsipal, ngunit maaari rin nitong dagdagan ang pangangailangan sa likwididad dahil kailangang magkasabay na magamit ang lahat ng kinakailangang asset.

5. Irekord ang Kinalabasan sa Programmable Payments

Dapat nakalagay ang mga kontrol sa labas ng patakaran pati na rin sa loob nito. Ang pagkakakilanlan, sanction, limitasyon sa paggastos, emergency stop, at mga pamamaraan ng pag-upgrade ay mga tungkulin ng pamamahala. Ang isang self-executing contract na walang lehitimong proseso ng eksepsyon ay maaaring awtomatikong magpatupad ng maling kinalabasan nang mas epektibo.

Ang Ekonomiks ng Programmable Payments

Ang programmability ay nagpapababa ng koordinasyon at rekonsilyasyon kapag maraming aksyon ang nagbabahagi ng isang mapapatunayan na kundisyon. Maaaring makinabang ang escrow, supply-chain finance, royalties, collateral calls, at usage-based billing.

Ang pinakamalaking pagtitipid ay kung saan ang kasalukuyang proseso ay kinabibilangan ng paulit-ulit na pagmemensahe, manu-manong ebidensya, at hindi tiyak na paglipat. Kung ang orihinal na proseso ay isang simpleng direct debit na, ang pagdaragdag ng komplikadong ledger ay maaaring magpataas ng gastos.

Ang composability ay nagpapahintulot sa mga patakaran na mag-ugnay, ngunit lumalaki ang pag-asa sa bawat panlabas na kontrata at pinagmulan ng datos. Dapat sukatin ang kahusayan sa pananalapi laban sa kaugnay na panganib ng software, oracle, at pamamahala.

Mga Paraan ng Pagkabigo sa Programmable Payments

• Maling espesipikasyon: Maaaring tapat na isakatuparan ng code ang patakaran na hindi tumutugma sa komersyal na kasunduan.
• Kabiguan ng oracle: Ang nag-uudyok na katotohanan ay maaaring mali, luma, hindi magagamit o sinadyang manipulahin.
• Hindi nababaliktad: Ang awtomatikong huling pag-aayos ay maaaring mag-iwan ng kaunting oras upang pigilan ang pandaraya o itama ang mga pagkakamali sa input.
• Komposabilidad: Ang isang kabiguan sa isang konektadong kontrata ay maaaring kumalat sa iba pang maayos na transaksyon.
• Awtoridad: Dapat malinaw kung sino ang maaaring mag-pause, mag-upgrade, magtalo o magpatong-hari sa mekanismo.

Halimbawang Praktikal ng Programmable Payments

Isipin ang isang lease ng kagamitan na binabayaran batay sa napatunayang paggamit ng makina. Nag-uulat ang sensor ng oras ng operasyon; pinapatunayan ng software ang aparato at ikinumpara ang paggamit sa kontrata; pinahihintulutan ng account ng nagbabayad ang isang limitadong halaga; at inilalabas ang utos ng bayad buwan-buwan. Ang mas pinagsamang tokenized na sistema ay maaaring sabay na i-update ang natatanggap sa lease at ang bayad. Sa alinmang disenyo, pareho pa rin ang mahahalagang tanong: sino ang magpapatunay sa sensor, ano ang mangyayari kung ito ay offline, maaaring bang hamunin ng customer ang nabasang datos, at aling ledger ang magpapatunay ng huling bayad?

Ebidensya sa Likod ng Programmable Payments

Ipinaliwanag ng BIS saklaw ng tokenisasyon at ang balangkas ng sistema ng pananalapi sa hinaharap nito kung paano maaaring pagsamahin ng mga karaniwang ledger at programmability ang mensahe, mga asset, at pag-settle. Ipinapakita rin nito na nananatili ang mga institusyonal at pamamahalang antas.

Ang papel ng Federal Reserve tungkol sa teknolohiyang distributed ledger sa mga pagbabayad, clearing, at settlement ay isang kapaki-pakinabang na kontrapuntong salik sa mga purong code na salaysay dahil inilalarawan nito ang parehong mga pagkakataon at operasyonal na hamon.

Ano ang Nagbabago sa Programmable Payments?

Inilarawan ng BIS ang tokenization bilang pagsasama ng impormasyon tungkol sa mga asset at pagmamay-ari kasama ang mga patakaran at pamamahala ng platform. Sinusuri ng pananaliksik sa unified-ledger ang paglalagay ng tokenized na pera ng central bank, pera ng komersyal na bangko, at mga asset sa isang karaniwang programmable na kapaligiran. Sa mas malapit na termino, ang mga API at request-to-pay na serbisyo ay magpapagawa ng karaniwang deposito na mas kondisyonal at awtomatiko. Malamang na magiging hybrid ang hinaharap: reguladong pera, programmable na workflow, at piniling mga shared ledger na konektado sa pamamagitan ng malinaw na kontrol.

Mga Tanong na Itanong Tungkol sa Programmable Payments

• Sa define rule, aling rekord ang nagpapatunay na tinukoy ng mga partido ang kondisyon, awtoridad, halaga, destinasyon, at petsa ng pagwawakas.
• Sa observe event, aling rekord ang nagpapatunay na ipinapakita ng mapagkakatiwalaang datos kung naganap na ang kondisyon.
• Sa validate, aling rekord ang nagpapatunay na sinusuri ng software ang pagkakakilanlan, pahintulot, pondo, patakaran, at kalagayan ng patakaran.
• Sa execute atomically, aling rekord ang nagpapatunay na ang bayad at ang kaugnay na asset o rekord ay sabay na na-update o hindi man lang.
• Sa record outcome, aling rekord ang nagpapatunay na pinananatili ng sistema ang ebidensya, katayuan, mga eksepsiyon, at anumang natitirang obligasyon.

Ano ang Dapat Basahin Pagkatapos ng Programmable Payments

Upang makita kung saan ito patutungo, basahin ang Paano Magbabago ng Tokenization at Agentic Pay ang mga Pagbabayad. Para sa pundasyunal na taksonomiya ng mga asset, magpatuloy sa Paliwanag sa Digital Assets.

Pangunahing Kaalaman sa Programmable Payments

Ang programmable money ay pinakamabisa kapag nililimitahan nito ang diskresyon at lumilikha ng mas mahusay na ebidensya. Kapag malabo ang pinagmulan ng datos, awtoridad sa pag-override, o landas ng pag-recover, mas pinapabilis ng awtomasyon ang pagkakamali kaysa gawing mas matalino ang bayad.

Mga Pinagmulan para sa Programmable Payments

• BIS: Ang tokenisation continuum
• BIS blueprint para sa hinaharap na sistemang pananalapi
• BIS: Ang hinaharap na sistemang pananalapi mula sa bisyon hanggang sa realidad
• Federal Reserve: DLT sa Pagbabayad, Clearing, at Settlement