Semua kegiatan ekonomi secara historis dibangun di atas perantara. Apa pun, bahkan transaksi sederhana antara kedua pihak disertai dengan keterlibatan berbagai perantara - bank, pertukaran, lembaga kliring, dll. Pengecualian perantara mungkin akan membuat interaksi lebih efisien. Jadi mengapa tidak mencoba membangun infrastruktur baru yang terdesentralisasi berdasarkan blockchain, di mana peserta dalam transaksi dapat bekerja secara langsung? Dalam posting ini, kita akan berbicara tentang bagaimana kita memulai perjalanan kita ke infrastruktur seperti itu: kita mengembangkan transaksi blockchain dan akhirnya melakukan repo - pinjaman uang yang dijamin oleh sekuritas.
Obligasi jangka pendek
Transaksi keuangan OTC pertama kami di blockchain adalah penerbitan obligasi jangka pendek dari operator seluler MTS dengan partisipasi dari National Settlement Depository (NSD). Ini adalah semacam "bank sentral" dari semua tempat penyimpanan. Deposit adalah perantara infrastruktur yang menyimpan catatan pemilik sekuritas dan menerbitkannya.
Dalam transaksi itu, MTS, dengan menyebut fungsi kontrak pintar, dicatat dalam blockchain sebagai ekspresi keinginan untuk menjual sekuritas ke Sberbank, dan itu mengkonfirmasi dalam blockchain perjanjiannya dengan ketentuan-ketentuan transaksi. Perintah balasan yang ditandatangani oleh kedua belah pihak diterima oleh NSD, yang mengeksekusi mereka dalam sistem akuntansi mereka. Selain itu, blockchain menampilkan akun peserta transaksi dalam sekuritas dan uang.
Dalam proyek itu, kami memilih platform
Hyperledger Fabric 1.1 open source, yang dirancang untuk membuat solusi blockchain perusahaan tertutup. Blokir publik tidak cocok di sini, karena kita perlu memastikan privasi data. Kami menghadapi keterbatasan seperti itu dalam pilot anjak Sberbank dengan M. Video, yang diimplementasikan pada blockchain Ethereum. Sebaliknya, Hyperledger Fabric memungkinkan Anda untuk menempatkan semua peserta dalam transaksi di saluran khusus di mana mereka dapat bertukar informasi yang diperlukan dan memprosesnya dengan kontrak pintar berfitur lengkap.
Kode sumber proyek obligasi MTS diunggah ke publik di GitHub. Bahkan tanpa masuk ke dalam algoritma pekerjaan, Anda dapat memahami bahwa dalam siklus hidup transaksi, blockchain diberi peran yang agak sederhana sebagai transportasi pesanan kliring. Di sisi lain, berdasarkan instruksi ini, saldo akun berubah - jadi dari sudut pandang logika bisnis, ini lebih menarik daripada layanan manajemen dokumen elektronik sederhana.
Keuntungan utama dari solusi ini adalah fleksibilitas. Skema “dua rekanan dan pendaftar” mencakup hampir semua transaksi di pasar OTC, dan dengan perubahan kecil - sebagian besar transaksi komersial pada umumnya.
REPO 1.0
Dalam proyek baru di blockchain, kami memutuskan untuk menunjukkan bagaimana menerapkan perjanjian pembelian kembali dalam sistem desentralisasi - pinjaman uang terhadap sekuritas. Biasanya, ini dan transaksi OTC lainnya melalui perantara - penyimpanan, kliring, broker.
Dalam proyek ini, kami menandatangani perjanjian pembelian kembali antara Sberbank dan mitra asing. Sudah menggunakan Hyperledger Fabric versi 1.2. Dibandingkan dengan obligasi MTS, kami memiliki dua perbedaan:
- Hanya dua peserta dalam transaksi yang terhubung ke blockchain, yang deposannya - Euroclear dan Clearstream - menerima semua pesanan melalui saluran transmisi data tradisional dari kantor belakang Sberbank dan rekanannya.
- Dalam kontrak pintar, kami menerapkan logika bisnis yang kompleks: kutipan harian dari keamanan yang berfungsi sebagai jaminan untuk pinjaman tersebut diunduh ke blockchain, dan kontrak pintar menghitung kebutuhan dan jumlah pembayaran awal, dengan mempertimbangkan perubahan biaya jaminan, diskon, kalender pertukaran keluar dan parameter lainnya. Sinkronisasi P2P dari algoritma perhitungan antara peserta tidak dapat diperoleh tanpa registri terdistribusi. Ini jauh lebih nyaman daripada perhitungan independen kewajiban dan jumlah masing-masing pihak - tidak ada rekonsiliasi yang memakan waktu, tidak ada konfirmasi.
Antara rekanan mengatur obrolan dan alur kerja di dalam saluran. Data tentang mereka disimpan di blockchain. Setelah setiap perubahan dalam registri terdistribusi, anggota saluran menerima peringatan email.
"REPO 1.0" kami bekerja dari sisi hukum. Dengan bantuan satu firma hukum besar, dilakukan analisis terhadap kasus-kasus Pengadilan Tinggi London. Selain itu, EDS bank dan mitranya menggunakan algoritma kriptografi yang berbeda.
Bagaimana cara kerja REPO 1.0?
Setiap pihak dalam transaksi memiliki simpul blockchain sendiri. Semua node terhubung satu sama lain dalam jaringan P2P. Misalkan Anda perlu membuat kesepakatan. Kami menggunakan kontrak pintar antara para pihak untuk transaksi, di mana instrumen keuangan sepenuhnya dijelaskan.
Setelah pembuatan kontrak di pihak kami, pedagang menandatanganinya. Klien juga meninjau dan menandatangani kontrak. Kemudian tanda tangan ditinjau dan diverifikasi. Dalam hal ini, transaksi dilakukan berdasarkan hukum Inggris, data pada tanda tangan digital elektronik dimasukkan ke dalam dokumen GMRA. Untuk penandatanganan oleh klien, diperlukan verifikasi bahwa orang yang berwenang hadir dalam sertifikat tanda tangan. Akhirnya, klien menerima kontrak dan menyetujui semua persyaratan. Anda dapat melampirkan sejumlah dokumen ke kontrak yang ditandatangani.
Setelah itu, kontrak menerima status "sedang bekerja". Kontrak "dalam proses" secara otomatis dihitung ulang setelah memuat harga pasar baru. Jika ada sekuritas dalam kontrak, harga pasar diambil, Loan-To-Value (LTV) dihitung ulang - rasio jumlah pinjaman dengan nilai sekuritas dalam sekuritas. LTV adalah salah satu istilah kunci dalam transaksi repo, artinya ditentukan dalam kontrak. Harga saham telah naik tajam - dan LTV menjadi kurang dari yang ditunjukkan dalam GMRA (ketika datang ke hukum Inggris). Dengan demikian, bank mengembalikan sekuritas kepada klien (sebagai salah satu opsi), karena dengan mempertimbangkan harga baru, ternyata bank memiliki keamanan yang lebih tinggi.
Tetapi jika LTV menjadi lebih besar, maka program ini memungkinkan Anda untuk mencetak pemberitahuan agunan - pemberitahuan kepada klien tentang perlunya membuat keamanan tambahan (saham atau uang) sehingga nilai LTV kembali ke nilai awal. Sebelumnya, pemberitahuan jaminan hanya bisa dikirim melalui pos, dokumen terpisah dibuat untuk ini, dan selama pembuatan dokumen-dokumen ini, LTV dapat berubah lagi. Sekarang kita melihat perhitungan yang sama dengan klien online, kita dapat dengan mudah berinteraksi.
Selain itu, program ini setiap hari menetapkan harga pembelian kembali sekuritas, dengan mempertimbangkan bunga. Jika klien tidak setuju dengan itu ketika memuat harga pasar, ia melihat log perhitungan ulang penuh - apa, apa yang menjadi, berapa harga yang dimuat, dari mana asalnya. Dan kemudian diskusi obrolan dimulai.
REPO 2.0
Kami ingin REPO kami di blockchain agar dapat memulai pergerakan aset nyata berdasarkan logika internal kami. Tetapi dalam REPO 1.0, karena kesulitan organisasi dengan menghubungkan deposan Barat, kami belum dapat mencapai ini. Jadi kami memulai pilot Repo 2.0 baru. Dia memiliki dua tujuan:
- Transaksi harus dilakukan dengan partisipasi dua pihak dan penyimpanan, untuk memanfaatkan infrastruktur proyek obligasi MTS sebaik-baiknya.
- Blockchain perlu diberdayakan untuk menilai kembali agunan dan mengatur margin call yang dapat secara otomatis dieksekusi oleh penyimpanan yang terhubung ke jaringan terdistribusi.
NSD segera ingin terhubung ke proyek. Untuk mendapatkan transaksi yang dimulai dalam blockchain di bidang konservatif undang-undang federal yang mengatur pasar keuangan domestik, kami bekerja dengan pengacara untuk perjanjian tambahan lima halaman dengan perjanjian manajemen dokumen elektronik. Itu ditandatangani oleh semua pihak untuk transaksi dan NSD.
NSD bertindak sebagai clearing house dalam transaksi ini. Dia melakukan semua instruksi tentang pergerakan dana dan sekuritas. Transaksi ini disimpulkan berdasarkan hukum Rusia.
Klien menerima kontrak dengan tanda tangan elektronik. Kemudian perjanjian tersebut diterima oleh Sberbank dengan tanda tangannya - perjanjian tersebut memeriksa kepatuhan semua parameter dengan nilai-nilai yang diperlukan dan wewenang orang yang diterima dari klien. Setelah itu, kontrak mulai bekerja. NSD mengunggah data pasar, kontrak pintar dihitung ulang.
Bagaimana cara kerja REPO 2.0?
Untuk menyebarkan jaringan dan berinteraksi dengan antarmuka klien dengan kode rantai, kami menggunakan solusi
Fabric Starter . Alih-alih antarmuka grpc standar untuk HLF, ia menyediakan API REST, yang dalam kasus kami secara signifikan mengurangi kompleksitas integrasi.
Jaringan naik sebagai berikut. Masing-masing dari tiga sisi setelah pra-instalasi pada server Docker meluncurkan Fabric Starter, yang menciptakan wadah dengan komponen-komponen dari node. Komponen ini termasuk rekan eksternal untuk berinteraksi dengan organisasi lain dan layanan REST API di mana node berinteraksi dengan aplikasi klien. Pada peluncuran Starter, jaringan blockchain juga dikonfigurasi dan saluran pribadi dibuat di mana kode rantai dengan kebijakan-dukungan diinstal. Dalam kasus kami, setiap transaksi harus memiliki tanda tangan dari ketiga peserta.
Selama fase pengujian, Docker Swarm digunakan untuk mengatur koneksi server peserta, namun, untuk tujuan membuat kesepakatan nyata, mereka beralih ke DNS. Platform itu sendiri bertanggung jawab untuk transportasi pesan, data ditransmisikan melalui Internet dengan enkripsi TLS.
Sisi teknis dari masalah ini
Proses pengembangan aplikasi terdistribusi pada HLF dimulai secara tradisional - dengan struktur data dan kode rantai (pada kenyataannya, satu set prosedur tersimpan), panggilan yang mengarah ke penyimpanan, modifikasi atau pembacaan struktur ini dari buku besar. Platform ini memungkinkan penggunaan berbagai bahasa pemrograman untuk pengembangan kode rantai dan DBMS untuk penyimpanan lokal. Kami lebih memilih Go dan CouchDB.
Esensi utama untuk proyek repo dalam model data kami adalah kontrak itu sendiri dan kewajiban anak perusahaannya. Mereka diciptakan untuk masing-masing dari dua pilot, serta untuk panggilan margin. Arsitektur ini merupakan langkah maju dibandingkan dengan model ikatan MTS, yang didasarkan pada esensi "Orde". Objek independen juga dibuat untuk sekuritas, yang dengan demikian sebagian tokenized. Tetapi pengembangan percobaan dengan manajemen akun dan tokenization uang virtual, kami memutuskan untuk menunda ke salah satu versi berikutnya dari solusi.
Fungsi utama dari solusi kami:
- Buat kontrak.
- Tanda tangani kontrak dengan EDS Anda yang mengonfirmasi penerimaan persyaratan kontrak.
- Unduh harga pasar dan mulai menghitung ulang nilai agunan. Penyimpangan dari ambang batas yang ditetapkan menyebabkan penciptaan kewajiban margin call baru.
- Cerminkan status kewajiban.
Di sisi teknis, prosedur evaluasi ulang paling menarik di sini. Mari kita analisa lebih detail.
Dalam proses bisnis, prosedur harus diluncurkan sekali sehari, setelah Oracle (dalam uji coba "REPO 2.0" yang dilakukan oleh NSD) mengunggah penawaran harga sekuritas ke dalam sistem.
func (t *CIBContract) recalculationData(stub shim.ChaincodeStubInterface, loadData *loadDataType, curDay string) pb.Response {...}
Siklus utama dari prosedur berjalan melalui semua sekuritas yang kutipannya telah diperbarui.
for _, securities := range loadData.Securities {...}
Selanjutnya, beberapa pemeriksaan dilakukan. Misalnya, jika pertukaran dengan mana data pasar diterima hari ini adalah hari libur, maka penghitungan ulang tidak boleh terjadi.
if t.checkHoliday(stub, contract.Settings.Calendars) == "yes" { hisYes := historyType{curDay, "LoadData. Calendar", "System", "LoadData. Today is holiday ! No load market data to contract !"} ... contract.History = append(contract.History, hisYes) … err = stub.PutState(contrID, contractJSONasBytes) }
Untuk menghitung harga obligasi yang diperbarui, hasil kupon yang masih harus dibayar (NDC) ditambahkan ke harga bersih yang dimuat. Pilot menerapkan dukungan untuk skema 30/360 untuk menghitung NKD.
priceIzm = float64(securities.Price + float64(securities.CouponRate)*float64((int(settlementDate.Year()) - int(dateStart.Year()))*360 + (int(settlementDate.Month()) - int(dateStart.Month()))*30 + (int(settlementDate.Day()) - int(dateStart.Day())))*100/360/100) curCurrVal = priceIzm
Jika mata uang transaksi berbeda dari mata uang di mana sekuritas dikutip, terjemahan pertukaran dilakukan.
if contract.GeneralTerms.PurchasePrice.Currency != securities.Currency { curCurrName = securities.Currency + "-" + contract.GeneralTerms.PurchasePrice.Currency for _, currency := range loadData.Currencies { if currency.Name == curCurrName { curCurrVal = priceIzm * currency.Value } } }
Sekarang kita perlu menghitung LTV. Pertahankan nilai koefisien lama untuk cerita.
oldCurLTV := contract.MarginingTerms.CurrentLTV
Hal ini diperlukan untuk memperhitungkan panggilan margin yang dilakukan selama masa transaksi. Persyaratan dapat datang dari kedua sisi, dan dalam dua bentuk:
- Efek. Peminjam membuat keamanan tambahan jika terjadi penurunan harga pasar keamanan. Kreditor mengembalikan bagian dari keamanan jika terjadi kenaikan harga.
- Uang Peminjam lebih awal dari jadwal membayar bagian dari pinjaman yang tidak lagi dijamin oleh jaminan yang lebih murah. Pemberi pinjaman meningkatkan jumlah pinjaman dalam menanggapi peningkatan nilai agunan.
Dalam kasus pertama, jumlah sekuritas dalam agunan diperbarui secara sederhana. Dan dalam hal menghasilkan uang dari mereka, itu juga perlu untuk mendapatkan keuntungan yang ditentukan dalam ketentuan tambahan transaksi.
for _, addCollateral := range contract.MarginingTerms.AddCollateral { currSumCollateral := addCollateral.Sum + (addCollateral.Sum*contract.MarginingTerms.RateOnCashMargin*float64(deltaColDate) / float64(contract.MarginingTerms.Basis))/100 ... allSumCollateral = allSumCollateral + currSumCollateral ... ht := historyType{curDay, System", "LoadData. Recalculation data(addCollateral) Contract " + contrID + " - currSumCollateral: " + strconv.FormatFloat(float64(currSumCollateral), 'f', 2, 64) ... } ... contract.History = append(contract.History, ht) }
Kami menghitung jumlah total pembelian kembali - pada kenyataannya, ini adalah jumlah pinjaman dengan bunga, yang harus kami bayar.
rePurchasePriceCur := contract.GeneralTerms.PurchasePrice.Sum + (contract.GeneralTerms.PurchasePrice.Sum*contract.GeneralTerms.RepoRate*float64(deltaSigningDate)/float64(contract.MarginingTerms.Basis))/100
Sekarang kita menghitung koefisien LTV. Untuk melakukan ini, kurangi sekuritas tunai dari harga pembelian kembali dan bagi nilai yang dihasilkan dengan nilai total sekuritas dalam sekuritas. Jumlah yang dikreditkan oleh kreditor ditandai dengan "-" dan akan ditambahkan ke harga pembelian kembali.
contract.MarginingTerms.CurrentLTV = (rePurchasePriceCur - allSumCollateral) * float64(100) / (float64(contract.GeneralTerms.PurchasedSecurities.Quantity) * curCurrVal)
Akhirnya, kami menghitung pemicu dalam kontrak. Prosedur yang sama akan membuat objek pesanan panggilan margin jika nilai LTV menyimpang dari koridor yang ditentukan.
contract = t.checkTriggerEvents(stub, "LoadData", contract, curDay, securities)
Dan tulis informasi ke histori untuk ditampilkan pada UI.
ht := historyType{curDay, "System", "LoadData. Recalculation data(change curLTV, ADTV) Contract " + contrID + " - oldCurLTV: " + strconv.FormatFloat(float64(oldCurLTV), 'f', 2, 64) + ", newCurLTV: " + strconv.FormatFloat(float64(contract.MarginingTerms.CurrentLTV), 'f', 2, 64)...} contract.History = append(contract.History, ht)
Untuk meringkas
Skema semacam itu dapat bekerja tidak hanya dengan sekuritas dan kontrak, tetapi juga dalam skenario lain. Misalnya, dengan pasokan listrik, di mana ada tarif berbeda, koneksi berbeda pada waktu yang berbeda. Atau dengan anjak piutang - meminjamkan kepada pemasok dengan sinyal pengiriman barang. Ada banyak kasus pengguna di bidang ekonomi, ketika semua orang menggunakan sumber data mereka sendiri yang harus diverifikasi.
Tujuan kami adalah untuk menciptakan jaringan yang menghubungkan bank dengan satu sama lain dan pelanggan mereka secara nasional, dan menggunakan kontrak pintar untuk menggambarkan di dalamnya kontrak bukan dari crypto, tetapi dari ekonomi tradisional - instrumen keuangan. Jaringan seperti itu akan stabil, terbuka, dan, sebagaimana seharusnya dalam jaringan P2P, tidak seorang pun di sini akan memiliki status khusus.