Core Banking Cloud vs On-Premise untuk BPR: Panduan Memilih

Rapat direksi sebuah BPR membahas penggantian sistem inti. Vendor menawarkan core banking berbasis cloud dengan biaya awal yang jauh lebih rendah. Staf TI menolak: “Data nasabah tidak boleh keluar dari kantor.” Direktur utama belum bisa memutuskan karena kedua pihak merasa benar.

Perdebatan seperti ini sering terjadi ketika sebuah BPR berencana melakukan migrasi sistem core banking. Perdebatan itu sebenarnya bukan tentang cloud atau bukan cloud. Yang diperdebatkan adalah siapa yang memegang kendali atas data, siapa yang bertanggung jawab saat sistem mati, dan bagaimana bank membuktikan keduanya kepada OJK.

Artikel ini membandingkan core banking cloud dan on-premise untuk BPR dan BPRS. Pembahasannya mencakup model penempatan, kewajiban menurut POJK 34/2025, biaya total, kontrol, pusat data dan pemulihan bencana, ketergantungan vendor, serta pertanyaan yang perlu dijawab sebelum memilih.

1. Mengapa pilihan ini muncul sekarang

Ada dua hal yang membuat keputusan ini mendesak pada akhir 2026.

Pertama, masa peralihan aturan TI hampir selesai. POJK 75/2016 tentang Standar Penyelenggaraan Teknologi Informasi BPR/BPRS berlaku sampai 17 Desember 2026. Penggantinya, POJK 34/2025, berlaku 18 Desember 2026. Pedoman teknisnya, PADK 43/2025, berlaku 17 Desember 2026. Artinya, bank yang menandatangani kontrak jangka panjang tahun ini perlu memastikan kontraknya tidak mengunci model yang tidak sesuai aturan baru.

Kedua, layanan digital menambah beban. Ketika BPR membuka aplikasi mobile atau bekerja sama dengan penyedia jasa TI, jumlah pihak yang menyentuh data nasabah bertambah. Pilihan penempatan sistem menentukan seberapa besar kendali bank atas data itu.

Pilihan cloud atau on-premise bukan soal selera. Keduanya bisa patuh. Yang membedakan adalah siapa yang mengerjakan apa, bukti apa yang dipegang bank, dan apa yang terjadi jika penyedia layanan berhenti bekerja.

2. Tiga model yang perlu dibedakan

Istilah “cloud” sering dipakai untuk semua hal yang tidak berada di kantor bank. Dalam praktik, ada beberapa model yang berbeda.

On-premise. Server dan aplikasi berada di pusat data milik bank atau di ruang sewa yang dikelola bank. Bank membeli perangkat keras, lisensi, dan mempekerjakan tim TI untuk merawatnya.

Private cloud. Infrastruktur disediakan khusus untuk satu bank, tetapi dikelola oleh penyedia jasa. Secara teknis bisa berada di pusat data penyedia atau di lokasi bank. Bank tetap memiliki kendali atas konfigurasi, tetapi tidak memegang perangkat kerasnya.

Public cloud. Bank menyewa sumber daya komputasi dari penyedia layanan publik. Data dan aplikasi berjalan di lingkungan yang dipakai bersama pelanggan lain, meskipun secara logis dipisahkan.

Perbedaan pentingnya bukan pada kata “cloud”, melainkan pada tiga hal: lokasi fisik data, siapa yang memegang akses administratif, dan siapa yang bertanggung jawab saat terjadi gangguan.

Apa pun modelnya, bank tetap dapat memakai penyedia jasa TI. POJK 34/2025 Pasal 27 ayat (1) membolehkan BPR dan BPRS menggunakan pihak penyedia jasa TI. Penjelasan pasal itu menyebut penggunaan komputasi awan, pengalihdayaan pengelolaan sistem TI, dan co-location pusat data sebagai contohnya.

3. Yang tidak berubah: bank tetap penanggung jawab

Kekhawatiran bahwa cloud memindahkan tanggung jawab kepada vendor tidak sejalan dengan aturan. POJK 34/2025 Pasal 27 ayat (2) huruf a menegaskan bahwa BPR dan BPRS tetap bertanggung jawab terhadap penyelenggaraan TI, meskipun menggunakan pihak penyedia jasa.

Penjelasan pasal itu menambahkan satu kalimat penting: bank tetap bertindak sebagai penyelenggara sistem elektronik untuk setiap sistem yang dipakai dalam kegiatan usahanya. Jadi, ketika nasabah tidak bisa bertransaksi karena layanan cloud terganggu, yang dinilai pertama kali adalah kesiapan bank, bukan kesiapan vendor.

Konsekuensinya muncul di beberapa pasal lain.

• Pasal 27 ayat (2) huruf g mewajibkan bank memastikan penyedia jasa memenuhi sebelas syarat, termasuk menjaga kerahasiaan data, menyediakan rencana pemulihan bencana yang teruji, dan memiliki klausul penghentian kerja sama.
• Pasal 27 ayat (5) mewajibkan penyedia jasa TI berbentuk badan hukum yang berkedudukan di Indonesia.
• Pasal 32 ayat (1) mewajibkan sistem elektronik ditempatkan pada pusat data dan pusat pemulihan bencana di wilayah Indonesia.
• Pasal 32 ayat (2) mewajibkan pusat data berada di lokasi dengan karakteristik risiko yang berbeda dari lokasi pusat pemulihan bencana.
• Pasal 18 mewajibkan rekam cadang data setiap akhir hari untuk seluruh aktivitas bank.

Dengan rangkaian kewajiban ini, pertanyaan yang tepat bukan “cloud atau on-premise”, melainkan “apakah model yang dipilih memungkinkan bank memenuhi seluruh kewajiban itu, dan apakah buktinya bisa diperiksa”.

4. Biaya: bukan hanya harga awal

Perbandingan biaya yang hanya melihat harga lisensi dan server akan menyesatkan. On-premise terlihat mahal di awal karena bank membeli perangkat keras dan lisensi. Cloud terlihat murah di awal karena bank membayar per bulan.

Namun, biaya on-premise tidak berhenti di pembelian. Ada biaya ruang, pendingin, listrik, jaringan, penggantian perangkat setiap beberapa tahun, lisensi basis data, dan gaji tim TI. Ada juga biaya uji pemulihan bencana dan audit.

Biaya cloud juga tidak berhenti di tagihan bulanan. Ada biaya migrasi, penyesuaian aplikasi, pelatihan, koneksi jaringan khusus, dan pengelolaan akses. Jika bank memakai beberapa layanan cloud, biaya pemantauan dan integrasi bisa tumbuh.

Cara yang lebih adil adalah membandingkan total biaya selama lima tahun dengan asumsi yang sama. Asumsi itu mencakup jumlah transaksi, jumlah cabang, kebutuhan penyimpanan data historis, target waktu pemulihan, dan jumlah staf TI yang tersedia.

Bagi BPR kecil, satu pertanyaan sering menentukan: apakah bank punya cukup orang untuk merawat server sendiri? Jika tidak, biaya on-premise yang terlihat murah akan berubah menjadi biaya kehilangan waktu dan risiko gangguan.

Ada juga biaya yang tidak muncul di tagihan mana pun, yaitu waktu direksi. Pada model on-premise, keputusan tentang penggantian perangkat, pemeliharaan, dan pemulihan bencana harus diambil sendiri. Pada model cloud, keputusan serupa tetap ada, tetapi bentuknya berubah menjadi pemeriksaan kontrak, pemantauan SLA, dan evaluasi penyedia.

Karena itu, perbandingan biaya sebaiknya dibuat dalam dua kolom: biaya tunai dan biaya waktu. Bank yang memilih cloud untuk menghemat biaya tunai perlu memastikan penghematan itu tidak habis untuk mengawasi vendor.

5. Kontrol dan keamanan

Kontrol bukan berarti bank harus memegang semua perangkat. Kontrol berarti bank bisa menentukan siapa yang boleh mengakses apa, bisa melihat siapa yang mengakses, dan bisa menghentikan akses itu kapan saja.

Pada model on-premise, kendali ini tampak jelas karena perangkat berada di ruang bank. Namun, kendali fisik tidak otomatis menjadi kendali logis. Jika satu administrator memiliki akses ke semua hal tanpa pemantauan, model on-premise tetap rapuh.

Pada model cloud, kendali fisik dipegang penyedia. Karena itu, bank perlu memastikan hal-hal berikut tersedia secara tertulis:

1. Pemisahan akses. Akses administrator penyedia tidak boleh otomatis menjadi akses ke data bank.
2. Enkripsi. Data dienkripsi saat disimpan dan saat dikirim, dengan kunci yang dikelola sesuai kesepakatan.
3. Jejak audit. Bank bisa mengunduh log aktivitas dan menyimpannya sendiri.
4. Hak audit. Bank dan OJK bisa memeriksa pengendalian yang dipakai penyedia.
5. Pemberitahuan insiden. Penyedia wajib memberi tahu bank atas setiap kejadian kritis.

Poin terakhir sejalan dengan POJK 34/2025 Pasal 27 ayat (2) huruf g angka 6. Penyedia jasa wajib menginformasikan setiap kejadian kritis yang dapat merugikan keuangan atau mengganggu operasional bank.

Satu kontrol yang sering terlupakan adalah pengelolaan superuser, yaitu akun dengan kewenangan sangat luas. Pada model on-premise, akun ini berada di tangan bank. Pada model cloud, akun serupa bisa dimiliki penyedia. Bank perlu memastikan ada pemisahan tugas, persetujuan berlapis, dan pencatatan setiap penggunaan akun itu. Tanpa kontrol tersebut, pemindahan data secara diam-diam sulit dideteksi.

Untuk pengamanan informasi, Pasal 15 mewajibkan prinsip kerahasiaan, integritas, dan ketersediaan, serta pengendalian otorisasi. PADK 43/2025 menambahkan bahwa pelindungan dalam kerja sama dengan penyedia jasa TI harus memadai, termasuk dalam penggunaan cloud.

6. Pusat data, DRC, dan lokasi data

Ini bagian yang paling sering disalahpahami. Cloud tidak menghapus kewajiban pusat data dan pusat pemulihan bencana. Ia hanya mengubah siapa yang mengelolanya.

POJK 34/2025 Pasal 32 ayat (1) tetap mewajibkan sistem elektronik ditempatkan pada pusat data dan pusat pemulihan bencana di wilayah Indonesia. Artinya, region cloud di luar Indonesia tidak memenuhi ketentuan ini untuk core banking, meskipun secara teknis layanannya lebih murah.

Pasal 32 ayat (2) menambahkan syarat lokasi: pusat data harus berada di lokasi dengan karakteristik risiko yang berbeda dari pusat pemulihan bencana. Dua region di pulau yang sama dengan sumber listrik dan jaringan yang sama belum tentu memenuhi syarat ini.

Selain lokasi, ada kewajiban lain yang harus dipenuhi pada model apa pun:

• Rekam cadang harian. Pasal 18 ayat (2) mewajibkan rekam cadang setiap akhir hari untuk seluruh data aktivitas bank.
• Pencatatan transaksi. Pasal 19 mewajibkan seluruh transaksi tercatat pada pembukuan di akhir hari yang sama.
• Uji pemulihan bencana. Pasal 16 ayat (3) mengatur frekuensi uji minimal, yaitu sekali dalam dua tahun bagi bank yang menyediakan layanan digital, dan sekali dalam tiga tahun bagi bank lainnya.
• Kaji ulang rencana. Pasal 16 ayat (4) mengatur kaji ulang rencana pemulihan bencana dengan frekuensi yang sama.

Bagi bank yang memiliki modal inti paling sedikit Rp50 miliar atau menyediakan layanan digital, Pasal 17 mewajibkan penyediaan pusat pemulihan bencana. Pusat itu boleh dimiliki sendiri atau bekerja sama dengan penyedia jasa TI.

Pertanyaan praktis yang perlu diajukan ke penyedia: di kota mana data disimpan, di kota mana replikanya, apakah kedua lokasi memakai penyedia listrik dan jaringan yang sama, dan apakah bank bisa mendapatkan bukti uji pemulihan.

7. Ketergantungan vendor dan jalan keluar

Risiko terbesar cloud bukan gangguan singkat. Risiko terbesarnya adalah bank tidak bisa pindah ketika hubungan kerja sama berakhir.

POJK 34/2025 sudah mengantisipasi hal ini. Pasal 27 ayat (2) huruf g angka 8 mewajibkan penyedia memiliki mekanisme penghentian kerja sama. Angka 10 mewajibkan penyedia bersedia menyepakati penghentian lebih awal jika kerja sama menghambat pengawasan OJK.

Pasal 28 menambahkan prosedur saat layanan terganggu. Bank wajib melaporkan kepada OJK paling lama tiga hari kerja setelah kondisi diketahui, memutuskan tindak lanjut, dan melaporkan penghentian penggunaan penyedia paling lama sepuluh hari kerja setelah penghentian.

Agar hak itu bisa dipakai, kontrak perlu memuat hal-hal yang konkret:

• Format data keluar. Bank berhak menerima seluruh data dalam format yang bisa dibaca sistem lain.
• Batas waktu penyerahan. Data diserahkan dalam jangka waktu tertentu setelah kontrak berakhir.
• Bantuan transisi. Penyedia membantu proses pindah, bukan hanya menutup akses.
• Penghapusan data. Setelah data diserahkan, penyedia menghapus salinan dan memberi bukti.
• Tingkat layanan. SLA memuat waktu respons, waktu pemulihan, dan kompensasi jika tidak terpenuhi.

Tanpa klausul ini, biaya pindah bisa jauh lebih besar daripada biaya berlangganan. Bank akan berada dalam posisi tawar yang lemah, bukan karena teknologinya buruk, tetapi karena datanya sulit diambil.

8. Khusus BPRS: kepatuhan syariah

BPRS memiliki satu lapisan kewajiban tambahan. POJK 34/2025 Pasal 27 ayat (4) mewajibkan penggunaan penyedia jasa TI disertai opini dewan pengawas syariah dan/atau hasil reviu fungsi kepatuhan syariah, jika terdapat prinsip syariah yang harus dipenuhi.

Dalam praktik, pertanyaannya mencakup hal-hal seperti: bagaimana sistem menangani akad, bagaimana bagi hasil dihitung, bagaimana dana Ziswaf dipisahkan, dan apakah penyedia memahami larangan riba dalam pemrosesan transaksi.

Pilihan cloud tidak menghapus kebutuhan ini. Yang berubah hanya lokasi server. Prinsip syariah tetap harus dibuktikan pada aplikasi dan proses, bukan pada gedung tempat server berada. Panduan pemisahan dana sosial ada di artikel mengelola dana Ziswaf di BPRS dan BMT.

9. Tujuh pertanyaan sebelum memilih

Sebelum menandatangani kontrak, direksi perlu mendapat jawaban tertulis atas pertanyaan berikut.

Pertanyaan	Mengapa penting
Di mana pusat data dan pusat pemulihan bencana berada?	Pasal 32 mewajibkan keduanya di Indonesia dengan risiko berbeda
Siapa yang memegang akses administrator?	Menentukan siapa yang bisa melihat atau mengubah data
Bagaimana bank mendapatkan log aktivitas?	Diperlukan untuk audit dan investigasi
Berapa target waktu pemulihan dan kehilangan data?	Menentukan kesiapan saat gangguan
Apa isi klausul penghentian kerja sama?	Melindungi bank saat harus pindah
Apakah penyedia bersedia diperiksa OJK?	Pasal 27 mewajibkan akses dan kesediaan diperiksa
Bagaimana biaya total lima tahun?	Menghindari perbandingan yang hanya melihat harga awal

Jika salah satu jawaban tidak jelas, keputusan sebaiknya ditunda. Ketidakjelasan kontrak akan menjadi masalah pada saat paling tidak nyaman, yaitu ketika sistem terganggu atau pengawas meminta bukti.

10. Pola campuran yang sering dipakai

Banyak bank tidak memilih salah satu secara murni. Mereka memakai kombinasi yang disesuaikan dengan kemampuan.

Core on-premise, cadangan di cloud. Server utama berada di kantor pusat atau pusat data sewa, sementara rekam cadang disimpan di penyimpanan cloud. Pola ini menjaga kendali harian dan memenuhi syarat rekam cadang di lokasi terpisah, asalkan lokasi cloud berada di Indonesia dan skema pemulihannya diuji.

Core cloud, DRC dikelola sendiri. Aplikasi berjalan di cloud, tetapi bank menyiapkan lokasi pemulihan sendiri. Pola ini menuntut bank memiliki tim yang mampu menjalankan sistem saat penyedia bermasalah.

Core cloud penuh dengan pengelolaan bersama. Penyedia mengelola infrastruktur dan aplikasi, bank mengelola akses, kebijakan, dan pengawasan. Pola ini paling bergantung pada kualitas kontrak dan kemampuan bank memantau.

Apa pun polanya, prinsipnya sama: bank harus tahu di mana data berada, siapa yang bisa mengaksesnya, dan bagaimana layanan dipulihkan. Ketiga hal itu harus bisa dijelaskan kepada OJK dalam bahasa yang sederhana, bukan hanya dalam diagram arsitektur.

11. Kesalahan umum

Pertama, menganggap cloud otomatis lebih murah. Biaya migrasi, integrasi, dan pengelolaan akses sering tidak masuk perhitungan awal.

Kedua, menganggap on-premise otomatis lebih aman. Keamanan ditentukan oleh kontrol akses dan pemantauan, bukan oleh lokasi perangkat.

Ketiga, memilih region cloud di luar Indonesia. Ini melanggar Pasal 32 dan sulit diperbaiki setelah data masuk.

Keempat, menandatangani kontrak tanpa klausul keluar. Bank baru menyadari masalahnya ketika ingin pindah penyedia.

Kelima, tidak menguji pemulihan. Rencana yang tidak pernah diuji hanya menjadi dokumen.

Keenam, menyerahkan seluruh keputusan teknis kepada vendor. Bank tetap penanggung jawab, termasuk saat vendor gagal.

Kesalahan-kesalahan ini biasanya muncul karena keputusan diambil terlalu cepat, bukan karena teknologinya salah. Karena itu, waktu paling berharga dalam proyek ini adalah waktu yang dipakai untuk memeriksa kontrak dan menguji skenario.

12. Kesimpulan

Cloud dan on-premise sama-sama dapat memenuhi aturan OJK. Yang menentukan bukan nama modelnya, melainkan apakah bank bisa memenuhi kewajiban Pasal 17 sampai Pasal 19, Pasal 27 sampai Pasal 28, dan Pasal 32 POJK 34/2025.

Sebelum memilih, bank perlu menjawab tiga pertanyaan: di mana data berada, siapa yang memegang akses, dan bagaimana layanan dipulihkan. Jika ketiga jawaban itu jelas dan tertulis, pilihan model menjadi soal biaya dan kemampuan, bukan soal keyakinan.

Untuk BPR yang sedang menyiapkan penggantian sistem, keputusan penempatan sebaiknya diambil bersamaan dengan rencana migrasi. Keduanya saling menentukan, dan keduanya perlu bukti yang bisa diperiksa pengawas. Pola pemeriksaan TI oleh OJK dibahas di persiapan pemeriksaan OJK sistem IT BPR/BPRS.

HeaBank dapat dijalankan secara on-premise maupun cloud di wilayah Jakarta, dengan cadangan setiap jam, pemulihan multi-zona, dan pusat pemulihan bencana yang dirancang mengikuti ketentuan OJK. Rinciannya ada di halaman core banking HeaBank. Pemilihan akhir tetap bergantung pada kesiapan tim, kontrak, dan hasil uji bank sendiri.

Referensi

1. Otoritas Jasa Keuangan — “POJK Nomor 34 Tahun 2025 tentang Penyelenggaraan Teknologi Informasi oleh Bank Perekonomian Rakyat dan Bank Perekonomian Rakyat Syariah”. https://ojk.go.id/id/regulasi/Pages/POJK-34-Tahun-2025-Penyelenggaraan-Teknologi-Informasi-oleh-Bank-Perekonomian-Rakyat-dan-Bank-Perekonomian-Rakyat-Syariah.aspx
2. Otoritas Jasa Keuangan — “PADK Nomor 43/PADK.03/2025 tentang Penyelenggaraan Teknologi Informasi oleh BPR dan BPRS”. https://ojk.go.id/id/regulasi/Pages/PADK-43-PADK03-2025-Penyelenggaraan-Teknologi-Informasi-oleh-BPR-BPRS.aspx
3. Otoritas Jasa Keuangan — “POJK Nomor 75/POJK.03/2016 tentang Standar Penyelenggaraan Teknologi Informasi bagi Bank Perkreditan Rakyat dan Bank Pembiayaan Rakyat Syariah”. https://peraturan.bpk.go.id/Details/129781/peraturan-ojk-no-75-pojk032016-tahun-2016
4. Otoritas Jasa Keuangan — “SEOJK Nomor 15/SEOJK.03/2017 tentang Standar Penyelenggaraan Teknologi Informasi bagi BPR dan BPRS”. https://ojk.go.id/id/regulasi/Pages/SEOJK-tentang-Standar-Penyelenggaraan-Teknologi-Informasi-bagi-Bank-Perkreditan-Rakyat-dan-Bank-Pembiayaan-Rakyat-Syariah.aspx
5. Otoritas Jasa Keuangan — “POJK Nomor 9 Tahun 2024 tentang Penerapan Tata Kelola bagi BPR dan BPRS”. https://ojk.go.id/id/regulasi/Pages/POJK-9-2024-Penerapan-Tata-Kelola-bagi-BPR-dan-BPRS.aspx
6. Otoritas Jasa Keuangan — “POJK Nomor 41 Tahun 2017 tentang Persyaratan dan Tata Cara Pemeriksaan Bank”. https://ojk.go.id/id/regulasi/Pages/Persyaratan-dan-Tata-Cara-Pemeriksaan-Bank-.aspx
7. Otoritas Jasa Keuangan — “Perbankan Syariah dan Kelembagaannya”. https://ojk.go.id/id/kanal/syariah/tentang-syariah/pages/PBS-dan-Kelembagaan.aspx