Topik ketersediaan dana sempat dibahas dalam sebuah panggilan telepon dengan calon mitra besar beberapa minggu lalu. Kapan dana tersedia bagi penerima dalam sebuah transaksi elektronik biasanya sangat 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 untuk masalah tersebut.
Solusi tersebut 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 keperluan contoh. VCR3 sebenarnya dapat dioperasikan oleh pemilik aplikasi klien juga, selama perjanjian antara pemilik akun VCR3 dan pemilik aplikasi klien mengizinkannya.
Apakah hal 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 memperoleh lisensi yang tepat sehingga mereka dapat membiayainya dari neraca mereka. Solusi lain adalah bermitra dengan bank, dan solusi lainnya adalah bermitra dengan jenis penyedia likuiditas yang berbeda.
Meskipun aspek ekonominya bisa bervariasi, mari kita lihat 3 solusi potensial jika likuiditas dibiayai dengan menerima risiko transaksi dalam bentuk utang jangka pendek. Dalam contoh ini, ada 3 skenario biaya yang sering saya temui:
- Suku Bunga Fed Funds. Saat saya menulis ini untuk pertama kalinya, suku bunga ini berada di level 0,25% per tahun. 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 disediakan setiap hari. Saat kita melihat biaya sebenarnya, penting untuk memperhatikan berapa banyak dana yang diberikan dan untuk jangka waktu berapa lama.
Saat Anda mulai menerapkan lingkungan real-time, Anda dapat mulai merinci biaya hari demi hari, jam demi jam, menit demi menit, dan ya… detik demi detik.
Bunga harian sangat penting dalam skenario ini
Pada transaksi ACH yang umum, Anda mungkin menghadapi penundaan selama 2 hari. Jadi, jika Anda membutuhkan juta (karena jumlah ini mudah digunakan sebagai contoh), 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.
Lalu, siapa yang menanggung biayanya? Pemilik aplikasi klien biasanya menanggung biaya program yang dimungkinkan oleh penyedia likuiditas.
Singkatnya, jika kita hanya menggunakan suku bunga pinjaman yang saya sebutkan di atas, kita dapat mengasumsikan bahwa likuiditas sebesar juta setara dengan sekitar 64,38 per hari pada tingkat bunga 6%, yang diakumulasikan setiap hari.
Untuk menutupi selisih 2 hari tersebut, 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 karena pemilik aplikasi klien + penyedia likuiditas menanggung risiko untuk memberikan pengalaman pengguna yang lebih baik dan akses instan ke uang.
Biaya untuk menghadirkan ketersediaan dana secara real-time tidak lagi 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 |
Pemrograman hal-hal berisiko
Ketika sistem memungkinkan berbagai pihak untuk mengambil risiko secara real-time, kita dapat mulai mempertimbangkan siapa saja yang mungkin mengajukan 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 menyusun struktur hubungan Anda. Aspek teknis dalam mentransfer uang kini menjadi bagian yang mudah. Dulu justru sebaliknya!