Perusahaan Perlu Prosedur Baru untuk Transfer Uang di Era Voice Clone
Jam 16.42.
Tim finance lagi ngejar cut-off.
Telepon masuk.
Suara di ujung sana terdengar seperti direktur.
“Transfer invoice vendor ini sekarang ya. Besok keburu telat. Gue lagi di luar, nggak bisa buka laptop.”
Kalau perusahaan punya budaya “yang penting Pak Bos sudah bilang”, game over.
Masalah voice clone bukan sekadar teknologi bisa meniru suara.
Ia mengeksploitasi celah yang dari dulu ada: banyak organisasi masih mengandalkan authority informal untuk memindahkan uang.
AI cuma membuat penyamaran authority itu lebih murah.
FTC sudah memperingatkan bahwa voice cloning dapat digunakan untuk meniru executive dan mencoba membuat employee mengirim uang atau membayar invoice palsu. Google Security juga memperkirakan AI-enabled vishing, termasuk peniruan suara eksekutif atau staf IT, menjadi ancaman yang makin penting pada 2026.
Di Indonesia, Komdigi pada Juli 2026 juga mengingatkan bahwa scam telepon makin canggih karena AI dapat meniru suara orang lain dan pejabat.
Perusahaan tidak bisa menjawab ancaman ini dengan satu training:
“Kalau suara terdengar robotik, jangan transfer.”
Itu akan basi.
Prosedur transfer harus aman walaupun suara palsunya sempurna.
Ini berarti identity verification dan payment authorization perlu dipisahkan dari conversation.
Bos boleh menelepon.
Vendor boleh WhatsApp.
CFO boleh video call.
Semua itu komunikasi.
Uang bergerak hanya lewat prosedur.
Kalau prinsip ini benar-benar diterapkan, voice clone kehilangan banyak power.
Prosedur pertama: tidak ada perubahan rekening hanya lewat email, chat, atau telepon.
Ini salah satu rule paling penting untuk perusahaan.
Vendor mengirim:
“Rekening kami berubah mulai hari ini.”
Jangan update lalu transfer.
Finance harus callback ke contact vendor yang sudah ada di master data.
Bukan nomor baru di email.
Bukan nomor yang diberikan pengirim.
Known contact.
Kalau vendor punya portal, verifikasi lewat portal.
Kalau kontrak punya contact resmi, gunakan.
Perubahan beneficiary adalah high-risk event.
Harus treated berbeda dari invoice biasa.
FBI juga menempatkan perubahan account number dan payment procedure sebagai situasi yang perlu diverifikasi melalui channel lain.
Prosedur kedua: dual approval yang tidak bisa dibypass lewat kata-kata.
Transfer di atas threshold tertentu membutuhkan dua approver.
Bukan “dua orang tahu”.
Dua approval di system.
Identity authenticated.
Log.
Kalau CEO bilang lewat telepon, “nggak usah dua approval”, sistem tetap menolak.
Ini bukan disrespect.
Ini control.
Rule yang bisa dibatalkan melalui telepon bukan rule.
Perusahaan perlu mengajari executive hal ini juga.
Kalau top management sendiri sering bypass proses karena urgent, mereka menciptakan training data perilaku untuk scammer.
Staff belajar bahwa emergency memang boleh bypass.
Attacker tinggal meniru emergency.
Prosedur ketiga: cooling-off untuk perubahan sensitif.
Perubahan bank account vendor tidak harus langsung berlaku dalam lima menit.
Bisa ada holding period.
Misalnya perubahan harus diverifikasi dan baru aktif setelah review.
Untuk supplier kritis, mungkin ada proses berbeda.
Intinya, jangan membuat satu email bisa mengubah destination uang dan langsung digunakan pada transaksi berikutnya.
Separation of change and payment.
Ini control klasik yang semakin valuable.
Prosedur keempat: callback protocol.
Callback bukan “telepon balik nomor tadi”.
Itu pointless.
Nomor tadi milik attacker.
Callback berarti gunakan nomor yang sudah tersimpan dari sumber terpercaya.
Vendor master.
Directory perusahaan.
Card.
Portal.
Contact yang sudah established.
Untuk executive internal, gunakan nomor company directory atau chat corporate.
Kalau voice clone juga digunakan di callback?
Itu mungkin.
Makanya callback bukan satu-satunya control.
Gabungkan dengan system approval.
Multi-channel.
Prosedur kelima: challenge yang nggak bergantung pada suara.
Untuk transaksi tertentu, bisa ada transaction-specific verification.
Nomor PO.
Contract ID.
Internal code.
Namun jangan mengandalkan pertanyaan yang datanya mudah ditemukan.
Nama anak direktur mungkin ada di social media.
Tanggal ulang tahun ada.
Project public ada.
Shared secret harus benar-benar secret atau gunakan authentication digital.
Lebih baik approval di platform dengan MFA atau passkey.
Human memory bukan vault.
Prosedur keenam: limit authority berdasarkan role.
Assistant CEO tidak otomatis boleh transfer karena menerima instruksi CEO.
Finance officer punya threshold.
Manager punya threshold.
Treasury punya role.
Bank portal punya segregation.
Jangan satu employee memegang create beneficiary, input transfer, dan final approve jika nilai material.
Voice clone sering mencoba mencari orang yang punya kemampuan langsung.
Segregation of duties membuat satu orang tidak cukup.
Ini mengurangi blast radius.
Prosedur ketujuh: emergency process resmi.
Ini sering dilupakan.
Perusahaan punya procedure normal.
Lalu ada situasi benar-benar urgent.
Server down.
Vendor critical.
Shipment tertahan.
Deal closing.
Kalau emergency process tidak ada, orang improvisasi.
Scammer hidup dari improvisasi.
Buat jalur emergency.
Misalnya:
Dua approver tetap wajib.
Callback wajib.
Treasury head notified.
Beneficiary new account tidak boleh same-day kecuali approval tambahan.
Log reason.
Post-transaction review.
Dengan begitu urgency tidak menghapus control.
Ia hanya memakai control berbeda.
Prosedur kedelapan: finance staff diberi hak untuk bilang “sebentar”.
Security culture sangat menentukan.
Staff junior harus boleh menahan transaksi kalau ada anomaly, bahkan ketika caller terdengar seperti direksi.
CEO perlu mengatakan secara eksplisit:
“Kalau saya minta transfer yang melanggar prosedur, anggap itu red flag. Verifikasi saya.”
Kalimat ini powerful.
Karena attacker mengeksploitasi hierarchy.
Kalau hierarchy justru mendukung verification, attack kehilangan leverage.
Perusahaan bisa melakukan tabletop exercise.
CFO palsu.
Voice call.
Urgent acquisition.
Secret deal.
Transfer sebelum jam bank tutup.
Lihat apa yang dilakukan tim.
Jangan hanya training slide.
Simulasikan decision.
Siapa telepon siapa?
System block?
Escalation?
Berapa lama?
Tabletop akan menemukan gap process.
Prosedur kesembilan: payment request tidak boleh hidup hanya di WhatsApp.
Indonesia sangat WhatsApp-heavy.
Vendor.
Owner.
Direksi.
Semua chat.
Practical.
Tapi chat sebaiknya menjadi notification, bukan system of record untuk payment.
Request masuk ERP, procurement system, atau ticketing yang punya identity dan audit.
“Pak, tolong cek request nomor 4821.”
Bukan:
“Pak transfer ke rekening ini ya.”
Bedanya besar.
Chat boleh cepat.
Authorization tetap formal.
Kalau company kecil belum punya ERP?
Bisa membuat control sederhana.
Form.
Shared approval log.
Dua orang.
Known account list.
Call verification.
Tidak harus software mahal.
Process lebih penting.
Prosedur kesepuluh: beneficiary allowlist.
Rekening vendor yang sudah diverifikasi disimpan.
Transfer biasa hanya ke daftar itu.
Rekening baru memicu enhanced verification.
Kalau scammer hanya bisa mengubah instruction lewat voice, mereka tetap tidak bisa menambah account tanpa process.
Ini mengurangi dependency pada manusia spotting scam.
System memberi friction.
Prosedur kesebelas: transaction threshold bukan hanya nominal.
Risk bisa datang dari kombinasi.
Nominal.
New beneficiary.
Country.
Time.
Urgency.
Executive request.
Multiple payment.
Unusual vendor.
Satu transfer Rp100 juta ke rekening lama mungkin normal.
Rp20 juta ke rekening baru yang diminta jam 17.00 via WhatsApp mungkin lebih suspicious.
Risk-based control bisa lebih smart.
Tidak semua transfer harus ribet.
Prosedur keduabelas: jangan pakai voice biometric sebagai satu-satunya faktor.
Kalau sistem internal memakai voice recognition, evaluasi ulang threat model.
Voice clone membuat static voiceprint lebih berisiko.
Liveness dan multi-factor mungkin dibutuhkan.
Untuk high-value banking, jangan satu suara membuka semua.
Authentication harus layered.
Prosedur ketigabelas: protect executive voice samples? Realistisnya sulit.
Direktur bicara di webinar.
Podcast.
Instagram.
Company town hall.
Voice sudah publik.
Jangan menjadikan secrecy suara sebagai defense.
Anggap attacker bisa mendapat sample.
Bangun procedure berdasarkan assumption itu.
Ini seperti email address.
Kita tidak berharap alamat email CEO rahasia.
Kita melindungi account dengan authentication.
Voice juga harus diperlakukan sebagai public-ish biometric ketika seseorang sering muncul online.
Prosedur keempatbelas: verify secrecy request.
Scammer suka bilang transaksi confidential.
“Akuisisi.”
“Legal case.”
“Jangan bilang siapa-siapa.”
Di perusahaan, memang ada transaksi confidential asli.
Makanya secrecy terdengar plausible.
Tapi confidential tidak berarti control-free.
Perusahaan perlu punya jalur approval confidential yang tetap melibatkan minimal pihak yang ditentukan.
Kalau deal sangat rahasia, daftar approver boleh kecil.
Tetap lebih dari satu.
“Rahasia” tidak boleh menghapus segregation.
Prosedur kelima belas: log semua exception.
Kalau transaksi dilakukan lewat emergency process, catat.
Siapa request.
Siapa verify.
Channel.
Reason.
Approver.
Beneficiary.
Waktu.
Setelah selesai, review.
Kalau exception sering terjadi, process normal mungkin buruk.
Atau ada executive yang sering bypass.
Fix.
Security incident sering lahir dari exception yang menjadi kebiasaan.
Prosedur keenam belas: incident response untuk salah transfer.
Kalau staff sadar lima menit setelah transfer bahwa kemungkinan scam, mereka harus tahu langkah.
Hubungi bank.
Escalate treasury.
Security.
Legal.
Report.
Indonesia Anti-Scam Centre yang dipimpin OJK menyediakan jalur laporan penipuan transaksi keuangan dan mendorong korban segera melapor agar lembaga keuangan terkait bisa menindaklanjuti. IASC juga menyarankan membuat laporan polisi dan menyiapkan bukti transfer serta percakapan.
Perusahaan harus memasukkan contact dan langkah ini dalam playbook lokal.
Bukan cari Google setelah kejadian.
Time matters.
Prosedur ketujuh belas: vendor education.
Perusahaan bisa punya control bagus, vendor lemah.
Email vendor compromised.
Attacker masuk thread asli.
Minta perubahan rekening.
Supply-chain trust.
Vendor penting perlu tahu procedure.
“Perubahan rekening tidak pernah valid hanya melalui email.”
Dengan rule bilateral, scammer lebih sulit.
Prosedur kedelapan belas: audit privilege bank.
Siapa yang bisa menambahkan beneficiary?
Siapa submit?
Siapa approve?
Apakah former employee masih punya token?
Apakah shared credential?
AI scam boleh canggih, tapi kadang uang berhasil pindah karena basic access governance berantakan.
Jangan fokus pada deepfake sampai lupa hygiene.
Prosedur kesembilan belas: no shame reporting.
Kalau employee merasa hampir tertipu, mereka harus bisa report tanpa takut diketawain.
Near miss valuable.
“Barusan ada telepon kayak Pak X, suaranya mirip banget.”
Security team bisa alert semua.
Kalau orang malu, signal hilang.
Culture penting.
Voice clone menargetkan manusia.
Defense juga perlu manusia yang berani bicara.
Prosedur kedua puluh: test CEO.
Ini bukan bercanda.
Executive adalah target high-value dan sekaligus persona yang paling powerful untuk ditiru.
Mereka perlu ikut simulation.
Jangan security training hanya untuk staff.
CEO juga harus disiplin memakai channel resmi.
Kalau direktur sering mengirim payment instruction dari nomor personal yang ganti-ganti, finance tidak punya baseline.
Leadership behavior adalah security control.
Ada satu kejadian yang perlu kita antisipasi secara desain.
Suatu hari voice clone akan cukup bagus sehingga finance staff tidak punya clue audio sama sekali.
No robotic artifact.
No weird pause.
No accent mistake.
Kalau hari itu datang, apakah perusahaan tetap aman?
Kalau jawabannya bergantung pada “semoga staff curiga”, belum aman.
Kalau jawabannya:
“Transfer tidak bisa berjalan tanpa beneficiary verification, system approval, dan second approver,”
jauh lebih kuat.
Era voice clone tidak membutuhkan finance team menjadi ahli deepfake.
Ia membutuhkan procedure yang tidak menganggap suara sebagai authorization.
Suara boleh bilang apa saja.
Uang tetap mengikuti control.
Bacaan terkait
Artikel ini berada dalam Cybersecurity & Trust dan mengikuti metodologi editorial Undercover.id. Format terkait tersedia di Explainer teknologi dan kebijakan digital.