Masa Depan Keuangan
Masa Depan Stablecoin Mungkin Lebih Besar dari Pembayaran
Dipakai membeli kopi bukan bagian yang menarik. Dipakai sebagai kaki penyelesaian di antara sistem — itu yang mengubah banyak hal.
Masa Depan Keuangan · Edisi 02
Saat Produk Keuangan Berubah Menjadi Software
Dokumen dibaca sekali lalu diarsipkan. Perangkat lunak dirilis berulang kali — dan itu mengubah cara produk keuangan gagal.
Produk keuangan tradisional pada dasarnya adalah dokumen. Ia disusun, ditinjau, disetujui, lalu berlaku dalam bentuk yang relatif tetap untuk waktu yang lama. Perubahan berarti dokumen baru, dan dokumen baru berarti proses persetujuan lagi.
Produk keuangan yang ditulis sebagai perangkat lunak bekerja dengan ritme berbeda. Ia dirilis, dipakai, diperbaiki, dirilis lagi. Ritme itu membawa keunggulan nyata — dan memindahkan letak risikonya ke tempat yang tidak biasa diperhatikan pemakai.
Apa yang benar-benar berubah
- Siklus perubahan memendek dari tahunan menjadi mingguan, kadang harian.
- Perilaku produk ditentukan oleh kode yang berjalan, bukan hanya oleh teks perjanjian yang ditandatangani.
- Kesalahan bisa muncul dari sisi yang sama sekali tidak keuangan: kekeliruan penulisan program, ketergantungan pada pihak ketiga, atau data harga yang keliru masuk.
- Sebaliknya, perbaikan juga bisa jauh lebih cepat sampai ke semua pengguna sekaligus.
Ketika produk menjadi perangkat lunak, pertanyaan "siapa yang mengubah ini terakhir kali, dan siapa yang meninjaunya" menjadi pertanyaan keuangan.
Risiko operasional naik pangkat
Di dunia dokumen, risiko operasional dianggap urusan belakang layar. Di dunia perangkat lunak, ia bergerak ke depan. Sebuah pembaruan yang salah bisa menghentikan penarikan dana, menampilkan angka yang keliru, atau membuka celah yang dieksploitasi — tanpa satu pun asumsi ekonomi berubah.
Otoritas keuangan di banyak yurisdiksi merespons dengan menaikkan bobot ketahanan operasional: pengujian, rencana pemulihan, pengelolaan ketergantungan pada penyedia pihak ketiga. Ini bukan urusan teknis semata; ia bagian dari kelayakan produknya.
Yang tidak ikut berubah
Kecepatan rilis tidak mengubah ekonominya. Sebuah produk yang lebih cepat diperbarui tetap harus menjawab pertanyaan yang sama: dari mana nilainya, siapa pihak lawannya, apa yang terjadi bila banyak orang keluar bersamaan. Perangkat lunak mempercepat perubahan, bukan menghapus kewajiban.
Yang juga tidak berubah adalah tanggung jawab. Ketika sebuah pembaruan merugikan pengguna, pertanyaan "siapa yang menanggung" tetap dijawab oleh perjanjian dan hukum, bukan oleh catatan perubahan kode. Sebagian layanan menyelesaikannya lewat kebijakan sukarela, sebagian lewat kewajiban yang punya dasar hukum — dan bagi pengguna, perbedaan antara keduanya besar sekali.
Ritme rilis dan ritme kepercayaan
Ada ketegangan yang menarik di sini. Perangkat lunak yang baik biasanya dirilis sering, dalam potongan kecil, supaya kesalahan cepat ketahuan. Produk keuangan yang dipercaya biasanya berubah jarang, supaya penggunanya bisa membangun kebiasaan di atasnya.
Menyeimbangkan keduanya adalah pekerjaan desain yang sesungguhnya: perubahan di lapisan mesin boleh sering, perubahan pada janji kepada pengguna sebaiknya jarang dan diumumkan. Layanan yang mencampur keduanya — mengubah syarat penting lewat pembaruan diam-diam — sedang meminjam kebiasaan dari dunia yang salah.
Pertanyaan baru yang layak diajukan
- Apa yang terjadi pada dana saya saat sistemnya sedang bermasalah atau dihentikan sementara?
- Siapa yang meninjau perubahan sebelum dipasang, dan apakah hasil tinjauan itu bisa dilihat?
- Bagian mana dari layanan ini yang bergantung pada penyedia lain, dan apa rencananya bila penyedia itu berhenti?
- Bila terjadi kesalahan yang merugikan pengguna, jalur ganti ruginya apa — kebijakan perusahaan, atau hak yang punya dasar hukum?
Empat pertanyaan itu terdengar seperti pertanyaan teknologi. Sebenarnya keempatnya adalah pertanyaan tentang uang — hanya saja letak jawabannya sudah pindah.
Sumber
Klaim faktual dalam tulisan ini bersandar pada dokumen publik berikut. Tautan mengarah ke laman resmi penerbitnya; cara kami memilih sumber dijelaskan di Standar Sumber.