Topik ketersediaan dana dibahas dalam sebuah panggilan telepon dengan calon mitra besar beberapa minggu yang lalu. Kapan dana tersedia bagi penerima dalam transaksi elektronik seringkali bergantung pada Jenis Transfer yang digunakan untuk mentransfer uang.
Di AS, terdapat banyak Jenis Transfer yang tidak menyediakan dana secara instan; oleh karena itu, selama bertahun-tahun banyak perusahaan telah mengatasi masalah tersebut dengan menciptakan solusi umum.
Solusi tersebut adalah memanfaatkan pihak ketiga yang turun tangan untuk menyediakan likuiditas sehingga memungkinkan penerima mendapatkan akses ke dana secara instan.
Berikut adalah mekanisme dasar dalam skenario normal tanpa penyedia likuiditas yang menggunakan Tipe Pelanggan Dwolla. Dalam contoh ini, VCR1 adalah pengirim dan VCR2 adalah penerima.
Penundaan standar ini dapat diatasi dengan melibatkan pihak ketiga untuk menyediakan likuiditas seperti yang disebutkan di atas. Cara yang lebih sederhana untuk menjelaskannya adalah bahwa seseorang akan meminjamkan uang tunai kepada penerima dan menanggung risiko jika pembayaran pengirim gagal.
Contoh bagaimana hal ini dilakukan dari perspektif aliran dana adalah sebagai berikut.
VCR3 mewakili entitas baru yang tidak termasuk dalam aliran dana awal. VCR3 dioperasikan atau dimiliki oleh penyedia likuiditas. Perlu dicatat bahwa hal ini disederhanakan demi membagikan contoh tersebut. VCR3 sebenarnya dapat dioperasikan oleh pemilik aplikasi klien selama kontrak antara pemilik akun VCR3 dan pemilik aplikasi klien mengizinkannya.
Apakah ini benar-benar mungkin?
Hal ini terjadi setiap hari di berbagai sistem di seluruh dunia. Seiring dengan masuknya keuangan tingkat tinggi ke dalam FinTech, atau sebaliknya, hal ini semakin sering terjadi.
Jadi, berapa biaya likuiditas?
Biayanya sangat bervariasi. Beberapa perusahaan mengumpulkan dana yang cukup dan mendapatkan lisensi yang tepat sehingga mereka dapat mendanainya dari neraca keuangan mereka. Solusi lain adalah bermitra dengan bank, dan solusi lainnya adalah bermitra dengan jenis penyedia likuiditas yang berbeda.
Meskipun aspek ekonominya mungkin bervariasi, mari kita lihat 3 solusi potensial jika likuiditas didanai dengan menerima risiko transaksi dalam bentuk utang jangka pendek. Dalam contoh ini, ada 3 skenario biaya yang sering saya temui:
- Suku Bunga Fed Funds. Suku bunga ini berada di level 0,25% per tahun saat saya menulis ini untuk pertama kalinya. Suku bunga Fed Funds terus turun setiap hari.
- Fasilitas kredit komersial. Mari kita asumsikan 6% per tahun. Meskipun suku bunga Fed lebih rendah, lembaga non-bank jarang menikmati tingkat suku bunga tersebut.
- Sesuatu yang lebih menantang. Mari kita asumsikan 12% per tahun. Inilah jenis suku bunga yang lebih sering ditemui.
Biaya tergantung pada mitra.
Komponen kunci di sini adalah likuiditas tidak disediakan secara tahunan, melainkan secara harian. Saat kita melihat biaya aktual, penting untuk melihat berapa banyak dana yang disalurkan dan untuk berapa lama.
Saat Anda mulai memperkenalkan lingkungan real-time, Anda dapat mulai merinci biaya hari demi hari, jam demi jam, menit demi menit, dan ya… detik demi detik.
Bunga harian penting dalam skenario ini
Pada transaksi "ACH" yang umum, Anda mungkin menghadapi penundaan selama 2 hari. Jadi, jika Anda membutuhkan juta (karena ini jumlah yang mudah untuk contoh ini), Anda dapat menggunakan salah satu solusi mitra yang saya sebutkan di atas untuk mendanai juta tersebut. Ingat, likuiditas hampir selalu didasarkan pada hubungan antara penyedia likuiditas dan pemilik aplikasi.
Jadi, siapa yang menanggung biayanya? Pemilik aplikasi klien biasanya menanggung biaya program yang dimungkinkan oleh penyedia likuiditas.
Singkatnya, jika kita hanya menggunakan tingkat suku bunga pinjaman yang saya sebutkan di atas, kita dapat mengasumsikan likuiditas sebesar juta adalah sekitar 64,38 per hari dengan suku bunga 6%, yang dibebankan setiap hari.
Untuk menutupi selisih 2 hari, Anda perlu membayar 28,76. Jika diasumsikan transaksi konsumen rata-rata sekitar 24, Anda dapat mendukung lebih dari 8.000 transaksi konsumen per hari dan memastikan pedagang dibayar secara real-time dengan meminjam uang dan menanggung risiko pengembalian. Hal penting yang perlu diingat di sini adalah konsumen tidak mengambil pinjaman apa pun. Dalam contoh ini, konsumen adalah pihak yang diuntungkan dari pemilik aplikasi klien + penyedia likuiditas yang menanggung risiko untuk memberikan pengalaman pengguna yang lebih baik dan akses instan ke uang.
Biaya untuk menghadirkan ketersediaan dana secara real-time tidaklah setinggi dulu.
Dengan tarif 0,25%, biaya 64,38 per hari menjadi ,85 per hari. Dengan masa tunggu 2 hari, biayanya menjadi 3,70 per .000.000.
Berikut adalah angka-angkanya jika Anda ingin memeriksanya. Angka-angka ini hanya untuk tujuan demonstrasi dan tidak boleh dianggap sebagai angka yang sempurna. Sejumlah variabel dapat mengubah biaya sebenarnya.
| Likuiditas | Tingkat Tahunan | Biaya Tahunan | 2 Hari | 1 Hari | Per Jam | Per Menit | Per Detik |
|---|---|---|---|---|---|---|---|
| 0.000.000 | 0,55% | 5.000 | 01,37 | 50,68 | ,28 | /bin/sh,105 | /bin/sh,0017 |
| .000.000 | 6,00% | 0.000 | 28,77 | 64,38 | ,85 | /bin/sh,114 | /bin/sh,0019 |
| .000.000 | 12,00% | 20.000 | 57,53 | 28,77 | 3,70 | /bin/sh,228 | /bin/sh,0038 |
| .000.000 | 20,00% | 00.000 | .095,89 | 47,95 | 2,83 | /bin/sh,381 | /bin/sh,0063 |
Mengelola risiko dalam pemrograman
Ketika sistem memungkinkan berbagai pihak untuk mengambil risiko secara real-time, kita dapat mulai mempertimbangkan siapa saja yang dapat melakukan penawaran setiap hari, setiap jam, setiap menit, dan setiap detik. Meskipun menarik, hal ini juga berbahaya jika dilakukan secara tidak bertanggung jawab.
Jika Anda sedang membangun sesuatu seperti ini, saya sangat menyarankan Anda untuk mempekerjakan seorang pengacara teknis yang dapat membantu Anda mengatur hubungan Anda. Aspek teknis dalam mentransfer uang kini menjadi bagian yang mudah. Dulu justru sebaliknya!