Bab III Ketentuan Dan Prosedur Final

Lampiran SE No. 12/1/DASP tanggal 21 Januari 2010 III.1

BAB III

KETENTUAN DAN PROSEDUR

A. Ketentuan dan Prosedur Umum

1. Disain Sistem

a. Komponen Sistem BI-RTGS

Sistem BI-RTGS terdiri dari 3 (tiga) komponen pokok, yaitu:

1) RTGS Central Computer (RCC)

RCC merupakan sistem komputer yang berada di lokasi Penyelenggara, yang digunakan untuk memproses Penyelesaian Akhir semua transaksi yang dikirim oleh Peserta. RCC terdiri dari 2 (dua) komponen utama, yaitu:

a) Interbank Funds Transfer System (IFTS)

IFTS adalah sub sistem yang berfungsi untuk menerima dan memproses data transaksi, menyediakan data-data di database RCC yang dapat di-enquiry oleh Peserta, laporan-laporan settlement dan laporan-laporan lainnya bagi semua Peserta.

b) Settlement Account (SA)

SA adalah sub sistem yang mencatat saldo Rekening Giro seluruh Peserta secara real time.

RCC terdiri dari RCC Utama dan RCC Back-up.

2) RTGS Terminal (RT)

RT merupakan sistem komputer yang berada di lokasi Peserta yang terhubung dengan RCC secara online yang berfungsi untuk melakukan berbagai transaksi.

RT terdiri dari RT Server Utama, RT Server Back-up, dan RT Workstation.

3) Jaringan komunikasi data

Jaringan komunikasi data terdiri dari:

a) infrastruktur komunikasi yang menghubungkan antara RT Peserta dengan RCC; dan

BAB …


b) infrastruktur komunikasi yang menghubungkan RCC dengan infrastruktur teknologi informasi USD/IDR PvP di Hong Kong.

b. Pengiriman Message Transaksi

Sistem BI-RTGS menggunakan V-shaped structure dalam proses pengiriman message dari Peserta pengirim kepada Peserta penerima melalui Bank Indonesia sebagai Penyelenggara Sistem BI-RTGS.

Dengan struktur ini, seluruh informasi yang terkandung dalam suatu transaksi akan dikirimkan oleh Peserta pengirim ke RCC dan akan diteruskan kepada Peserta penerima apabila transfer sudah di-settle di RCC di Penyelenggara.

2. Pelaksanaan Operasional RT

a. Struktur Organisasi

Struktur organisasi atau departemen dalam RT terdiri dari:

1) Central Department

Central department merupakan departemen yang mengelola RT Server yang langsung terhubung dengan RCC serta terdaftar sebagai Peserta dengan 1 (satu) member code. Setiap Peserta hanya mempunyai 1 (satu) central department yang dapat terhubung dengan maksimal 998 (sembilan ratus sembilan puluh delapan) subsidiary department. Central department mempunyai kewenangan untuk melakukan berbagai fungsi dalam RT termasuk untuk melakukan monitoring kegiatan dari subsidiary department-nya. Setiap central department harus memiliki paling sedikit 2 (dua) RT Server yang terdiri dari RT Server Utama dan RT Server Back-up serta 1 (satu) printer. RT Server tersebut terhubung dengan RT Workstation baik yang berada pada central department

Peserta Penerima

PesertaPengirim

Bank Indonesiasebagai Penyelenggara Sistem BI-RTGS

Dengan …


maupun subsidiary department, dimana jumlah RT Workstation pada seluruh departemen maksimal 999 (sembilan ratus sembilan puluh sembilan) workstation.

2) Subsidiary Department

Subsidiary department merupakan departemen yang hanya memiliki RT Workstation untuk melaksanakan berbagai fungsi RT dan memonitor kegiatan transaksi milik departemen yang bersangkutan. Untuk mengidentifikasi asal transaksi maka setiap subsidiary department diberikan department code.

b. Pengoperasian fungsi RT pada setiap departemen

Fungsi RT yang dapat dioperasikan untuk setiap departemen tergantung pada kebijakan masing-masing Peserta. Pada umumnya setiap departemen dapat melakukan fungsi-fungsi antara lain:

1) membuat (construct) transaksi keluar (outgoing transaction);

2) melakukan otorisasi, mengirim, mengubah dan membatalkan transaksi;

3) mencetak dan mengirim copy transaksi;

4) menayangkan (display) dan mencetak status transaksi;

5) menayangkan dan mencetak ulang rincian transaksi;

6) mengelola Sistem Antrian untuk transaksi dengan tingkat kepentingan normal yang berasal dari departemen masing-masing;

7) mengendalikan operasi printer;

8) mencetak laporan-laporan atas transaksi yang berasal dari departemen masing-masing;

9) melakukan fungsi supervisory; dan

10) memelihara dan meng-up-date database masing-masing.

c. Wewenang pengoperasian pada Operating System (O/S)

Kewenangan pengoperasian O/S pada masing-masing Peserta terdiri dari administrator, RT super, dan RT user.

1) Administrator (adm)

Administrator bertanggungjawab untuk:

a) mengelola user O/S yang meliputi RT super dan RT user; dan

b) melakukan set-up dan release aplikasi RT.

Apabila password administrator tidak dapat digunakan maka harus dilakukan install ulang oleh Peserta sendiri. Dalam hal Peserta mengalami kesulitan dalam melakukan install ulang, Peserta yang bersangkutan dapat melakukan hal-hal sebagai berikut:

a) Peserta mengajukan surat permintaan install ulang O/S yang ditandatangani oleh Direksi yang mempunyai spesimen tanda tangan di Penyelenggara dan ditujukan kepada:

bersangkutan …


Direktorat Akunting dan Sistem Pembayaranc.q. Bagian Penyelenggaraan SetelmenBank Indonesia, Gedung D Lantai 3Jalan MH. Thamrin No.2 Jakarta 10350

b) Peserta menyerahkan perangkat RT Server untuk dilakukan install ulang kepada Penyelenggara dengan alamat sebagaimana dimaksud pada huruf a).

2) RT super

RT super digunakan untuk:

a) Pendaftaran printer;

b) Reset user, system status, dan log on status yang masih dalam status in progress;

c) Restore database;

d) Ad hoc back-up; dan

e) Konfigurasi pencetakan laporan.

3) RT user

RT user digunakan untuk seluruh kegiatan pengoperasian RT Peserta.

d. Wewenang pengoperasian pada aplikasi RT

Kewenangan pengoperasian aplikasi RT pada masing-masing Peserta ditunjukkan oleh tingkatan user yang terdiri dari level administrator, supervisor dan operator.

1) Administrator (adm)

Penyelenggara akan memberikan 2 (dua) user dengan level administrator beserta password-nya kepada Peserta yang diwakili oleh Direksi atau pejabat yang diberi kuasa pada instalasi pertama. Untuk keperluan pengamanan aplikasi RT, Peserta diminta untuk mengubah password administrator segera pada hari yang sama setelah password diterima dari Penyelenggara.

User administrator bertanggungjawab untuk:

a) mengelola database aplikasi RT yang antara lain meliputi database member control, department, RT Workstation, Account Identifier Data (AID), dan Authenticator Text (AT); dan

b) mengelola user aplikasi RT yang meliputi pendaftaran, perubahan, dan penghapusan petugas-petugas yang ditunjuk dan menentukan kewenangan untuk mengoperasikan berbagai fungsi dalam aplikasi RT.

User administrator pada central department dapat mendaftarkan user-user dengan level administrator, supervisor dan operator, baik pada central department sendiri

sebagaimana …

harus …


maupun pada subsidiary department. Untuk pendaftaran user, diperlukan 2 (dua) user level administrator yang bertugas untuk mendaftarkan dan melakukan approval. Apabila password user setingkat administrator tidak dapat digunakan maka reset password hanya dapat dilakukan oleh 2 (dua) administrator lain. Apabila seluruh password user setingkat administrator tidak dapat digunakan maka reset password harus dilakukan oleh petugas yang ditunjuk dengan cara menjalankan CD aplikasi reset password yang telah diberikan oleh Penyelenggara.

2) Supervisor (spv)

Supervisor (spv) memiliki kewenangan operasional dalam aplikasi RT untuk melaksanakan berbagai fungsi yang berkaitan dengan kegiatan supervisi terhadap pekerjaan dari operator antara lain menyetujui (approve) dan mengirimkan transaksi atau aktivitas administratif lainnya. Kewenangan supervisor dapat dibatasi berdasarkan pemberian fungsi dan/atau pembatasan nominal (global limit) dalam pengiriman transaksi. Dalam hal password user setingkat supervisor tidak dapat digunakan maka reset password harus dilakukan oleh 2 (dua) user setingkat administrator.

3) Operator (opr)

Operator (opr) memiliki kewenangan untuk melakukan input data (construct data) ke dalam Sistem BI-RTGS sesuai dengan perintah transfer. User setingkat operator tidak dapat mengakses pengelolaan Sistem Antrian serta fungsi-fungsi supervisi. Setiap kegiatan yang berkaitan dengan pengiriman transaksi yang dilakukan oleh operator masih memerlukan persetujuan dari supervisor. Dalam hal password user setingkat operator tidak dapat digunakan maka reset password harus dilakukan oleh 2 (dua) user setingkat administrator.

3. Fungsi-fungsi dalam RT

Dalam RT terdapat fungsi-fungsi sebagai berikut:

a. System

System adalah fasilitas dalam Sistem BI-RTGS yang digunakan untuk melakukan kegiatan sebagai berikut:

1) System start-up dan department start-up

System start-up merupakan kegiatan mengaktifkan RT Server pada masing-masing Peserta. System start-up dilakukan oleh user setingkat administrator pada central department. Selanjutnya subsidiary department dapat melakukan department start-up yang dilakukan oleh user setingkat administrator pada subsidiary department atau oleh user setingkat administrator pada central department.

System start-up dilakukan pada setiap awal hari kerja setelah proses


batch pada hari kerja sebelumnya atau setelah pemeliharaan database.

2) System shut-down dan department shut-down

Department shut-down merupakan kegiatan untuk menonaktifkan department. Central department shut-down dilakukan oleh user setingkat administrator pada central department. Subsidiary department shut-down dilakukan oleh user setingkat administrator pada subsidiary department atau oleh user setingkat administrator pada central department. Subsidiary department shut-down harus dilakukan sebelum central department shut-down.

System shut-down merupakan kegiatan menutup sistem aplikasi RT pada akhir hari kerja (end of day system shut-down). Kegiatan ini dilakukan oleh user setingkat administrator pada central department setelah department shut-down. Setelah system shut-down, dilanjutkan dengan end of day process untuk persiapan proses hari kerja berikutnya.

3) Penutupan sistem dalam Jam Operasional (mid-day shut-down)

Peserta dapat melakukan penutupan sistem dalam Jam Operasional yang bersifat sementara. Setelah itu Peserta dapat mengaktifkan sistem kembali (system start-up) oleh user setingkat administrator pada central department untuk melanjutkan kegiatan operasional.

b. Interbank Fund Transfer System (IFTS)

IFTS adalah fasilitas dalam Sistem BI-RTGS yang digunakan untuk melakukan transaksi dengan kegiatan sebagai berikut:

1) Construct

Construct data transaksi keluar merupakan kegiatan input data transaksi berdasarkan perintah transfer dalam bentuk warkat atau data elektronik yang ditentukan oleh masing-masing Peserta. Construct data terdiri dari Construct Single Credit, Construct Multiple Credit dan Credit Notification. Hasil dari kegiatan ini adalah construct copy yang akan tercetak pada departemen yang bersangkutan. Kegiatan ini dilakukan oleh user setingkat operator yang telah didaftarkan ke dalam Sistem BI-RTGS.

2) Amend IFTS Transaction

Amend data merupakan kegiatan untuk melakukan koreksi data yang telah di-input setelah dilakukan reject oleh supervisor atau ditolak oleh RCC dengan status Negative Acknowledgement (NK). Hasil dari kegiatan ini adalah amend copy yang akan tercetak pada departemen yang bersangkutan. Kegiatan ini dilakukan oleh user setingkat operator yang telah didaftarkan ke dalam Sistem BI-RTGS.

department …


3) Reconstruct PvP transaction

Reconstruct PvP transaction merupakan kegiatan untuk melakukan koreksi atas data Transaksi PvP yang telah ditolak oleh RCC dengan status pemrosesan Rejected by Host (RH). Kegiatan ini dilakukan dengan menggunakan data Transaksi PvP yang telah di-input sebelumnya sehingga petugas tidak perlu meng-input ulang seluruh data.

Hasil dari kegiatan ini adalah reconstruct copy yang akan tercetak pada departemen yang bersangkutan. Kegiatan ini dilakukan oleh user setingkat operator yang telah didaftarkan pada Sistem BI-RTGS. Setelah kegiatan reconstruct ini masih diperlukan approval oleh user setingkat supervisor.

4) Approval/Reject IFTS

a) Approval merupakan kegiatan untuk melakukan persetujuan data transaksi yang di-input oleh operator.

b) Reject merupakan kegiatan untuk melakukan penolakan data transaksi yang di-input oleh operator.

5) Cancel Rejected IFTS

Cancel merupakan kegiatan untuk melakukan pembatalan data transaksi yang telah di-reject oleh supervisor.

6) Cancel PvP Transaction

Cancel PvP Transaction merupakan kegiatan untuk melakukan pembatalan data Transaksi PvP. Transaksi PvP yang dapat dibatalkan adalah transaksi yang memiliki status pemrosesan Pending for Matching (PM), PvP Matched (MT), Hold IDR Fund (HD) dan Hold Counterparty Currency (HC).

7) Queue handling

a) Queue handling merupakan kegiatan untuk melakukan pembatalan antrian dan resequence transaksi dengan tingkat kepentingan normal.

b) Dalam hal saldo Rekening Giro Peserta tidak mencukupi untuk menyelesaikan suatu transaksi maka transaksi yang bersangkutan akan dimasukkan dalam Sistem Antrian pada RCC.

c) Khusus untuk Mekanisme USD/IDR PvP, Transaksi PvP akan masuk ke dalam Sistem Antrian setelah menemukan transaksi sisi mata uang Dolar Amerika Serikat (berstatus pemrosesan PvP Matched (MT)) namun belum berhasil meng-hold dana sisi mata uang Rupiah karena ketidakcukupan saldo Rekening Giro Peserta pembayar sisi mata uang Rupiah, dan Transaksi PvP akan berstatus pemrosesan Pending for Holding IDR Fund (PH).

di- input …


d) Penanganan antrian dapat dilakukan oleh Peserta melalui fungsi Outgoing Queue Maintenance. Fungsi ini digunakan oleh Peserta untuk melakukan hal-hal sebagai berikut:

(1) Melihat daftar transaksi keluar dengan tingkat kepentingan prioritas dan normal;

(2) Mengubah nomor urut antrian transaksi dengan tingkat kepentingan normal. Pengurutan kembali nomor antrian agar tidak menggunakan nomor yang berurutan karena akan menyebabkan kesulitan apabila terdapat transaksi yang akan disisipkan diantara urutan yang telah ada; dan

(3) Membatalkan transaksi dengan tingkat kepentingan normal.

e) Pada saat cut off warning transaksi yang masih berada dalam antrian akan dibatalkan oleh RCC dan status transaksi akan menjadi Reject by Host Acknowledge Print (RH AK PR). Pada saat yang bersamaan, pada printer Peserta akan tercetak cancel copy.

f) Khusus untuk Mekanisme USD/IDR PvP, apabila Transaksi PvP pada saat PvP cut off masih berada dalam antrian (berstatus pemrosesan Pending for Holding IDR Fund (PH)), Transaksi PvP tersebut akan dibatalkan oleh RCC dan status pemrosesannya menjadi Rejected by Host (RH).

c. Audit Trail

Audit trail adalah fungsi yang digunakan untuk melihat dan/atau mencetak seluruh transaksi yang telah diproses oleh RT. Melalui fungsi ini dapat diperoleh informasi mengenai status dari transaksi baik transaksi keluar maupun transaksi masuk secara individual maupun ringkasannya dalam bentuk tayangan ataupun cetakan setiap saat pada Jam Operasional dengan masa retensi selama 25 (dua puluh lima) hari kerja. Central department dapat melihat seluruh transaksi, sedangkan subsidiary department hanya dapat melihat transaksi yang berasal dari subsidiary department yang bersangkutan. Melalui fungsi ini user dapat melakukan kegiatan sebagai berikut:

1) List/Print Transaction Status

Peserta dapat melihat dan/atau mencetak status transaksi saat ini atau transaksi periode sebelumnya.

2) List/Print Transaction History

Peserta dapat melihat dan/atau mencetak riwayat status selengkapnya untuk transaksi saat ini atau yang telah diproses, misalnya transaksi yang dikirim ulang karena adanya kegagalan transmisi.

(2) Mengubah …


3) List/Print Unfinished Transaction

Peserta dapat melihat transaksi-transaksi yang belum/tidak terselesaikan seperti transaksi yang diubah dan ditolak oleh supervisor dan yang ditunda karena dana tidak cukup.

4) Display/Reprint Transaction

Peserta dapat melihat tayangan dan/atau mencetak rincian transaksi-transaksi tertentu yang sedang berjalan maupun yang telah diproses.

5) Print Summary Report

Peserta dapat melihat dan/atau mencetak ringkasan seluruh transaksi yang dikirim dan diterima pada saat berjalan atau yang telah diproses.

d. Supervisory (Fungsi-fungsi pimpinan)

Fungsi-fungsi yang terdapat dalam menu supervisory adalah kegiatan yang dilakukan dalam rangka monitoring transaksi. Fungsi-fungsi ini diberikan kepada level administrator atau supervisor. Kegiatan-kegiatan yang terdapat dalam fungsi ini adalah:

1) Log-on ke RCC

a) Log-on adalah kegiatan untuk menghubungkan antara RT Server dengan RCC.

b) Log-on harus dilakukan setelah system start-up dan RCC open.

c) Dalam hal Peserta melakukan log-on sebelum RCC open maka Peserta harus melakukan log-on ulang agar RT terhubung secara online dengan RCC. Transaksi yang dikirim sebelum status RCC open harus di-construct ulang.

d) Keberhasilan proses log-on akan tertayang dan tercetak pada report log-on. Sebaliknya jika log-on tidak berhasil akan tertayang dan tercetak informasi penolakan disertai kode error dari RCC.

e) Dalam hal terjadi disconnect (force log-off) dengan RCC, maka Peserta harus melakukan log-on ulang.

f) Kegiatan log-on merupakan kewenangan central department.

2) Log-off dari RCC

a) Log-off adalah kondisi terputusnya hubungan antara RT dengan RCC yang disebabkan antara lain oleh:

(1) Peserta melakukan log-off;

(2) Status RCC cut off; atau

(3) Terjadi gangguan jaringan komunikasi data.

b) Kegiatan log-off sebagaimana dimaksud pada butir a) (1)

4) Display/Reprint …


merupakan kewenangan central department.

3) Member’s Enquiry

Fungsi ini disediakan bagi Peserta untuk melakukan kegiatan sebagai berikut:

a) Mencetak rekapitulasi mutasi transaksi (Member Own Total);

b) Melihat posisi saldo rekening (Account Position Enquiry);

c) Mencetak simulasi settlement saldo rekening (Simulated Settlement Balance); dan

d) Mencetak posisi rekening konsolidasi (Consolidated Bank Position Enquiry).

4) Retrieve Transaction from RCC

Merupakan fungsi untuk mengambil data (format cetak) transaksi yang telah di-settle di RCC. Data transaksi yang dapat diambil secara online dari RCC adalah data yang tersedia dalam jangka waktu 9 (sembilan) hari kerja terakhir.

5) Recap Transaction from RCC

Merupakan fungsi untuk mengambil data (format cetak) rekapitulasi seluruh transaksi. Jenis laporan rekapitulasi meliputi:

a) Member Total Recap Report

Member Total Recap Report merupakan laporan yang memperlihatkan ringkasan total transaksi IFTS yang dikirim dan diterima dari semua Peserta.

b) Detail Recap Report

Detail Recap Report merupakan laporan yang berisi rincian transfer-transfer keluar berdasarkan Input Sequence Number (ISN) yang ditentukan dan advis yang diterima berdasarkan Output Sequence Number (OSN) yang diberikan oleh RCC.

6) Send Administrative Message

Merupakan kegiatan pengiriman pesan dari Peserta kepada Penyelenggara atau Peserta lainnya. Pembuatan dan approval administrative message dilakukan oleh 2 (dua) user setingkat supervisor atau manager.

e. Enquiry

Fungsi ini dapat digunakan untuk melihat dan mencetak transaksi. Fungsi ini dapat diberikan kepada semua level kewenangan dalam Sistem BI-RTGS, yaitu kepada operator, supervisor maupun administrator.

User dari central department dapat melihat seluruh transaksi, sedangkan subsidiary department hanya dapat melihat transaksi yang dibuat oleh departemennya sendiri.

Fungsi Enquiry terdiri dari:

1) Unfinished IFTS Enquiry

b) Melihat …


Fungsi ini digunakan untuk melihat rincian transaksi IFTS yang berstatus belum selesai. Transaksi–transaksi ini adalah:

a) Transaksi yang telah di-construct namun belum mendapatkan persetujuan atau belum ditolak oleh supervisor;

b) Transaksi yang telah ditolak oleh supervisor atau oleh RCC tetapi belum diubah atau dibatalkan oleh supervisor;

c) Transaksi yang telah mendapat persetujuan awal (pre approval) namun masih memerlukan persetujuan lebih lanjut (final approval);

d) Khusus untuk Mekanisme USD/IDR PvP, meliputi Transaksi PvP (dengan TRN: IFTPvP00) yang berada dalam posisi:

(1) telah mendapat persetujuan namun belum menemukan transaksi sisi mata uang Dolar Amerika Serikat (status pemrosesan Pending for Matching (PM));

(2) telah menemukan transaksi sisi mata uang Dolar Amerika Serikat (status pemrosesan PvP Matched (MT));

(3) akan meng-hold dana sisi mata uang Rupiah pada Rekening Giro Peserta pembayar sisi mata uang Rupiah namun belum berhasil karena ketidakcukupan saldo (status pemrosesan Pending for Holding IDR Fund (PH));

(4) telah berhasil meng-hold dana sisi mata uang Rupiah pada Rekening Giro Peserta pembayar sisi mata uang Rupiah (status pemrosesan Hold IDR Fund (HD); atau

(5) siap untuk dilakukan Penyelesaian Akhir dimana holding dana sisi mata uang Dolar Amerika Serikat telah pula berhasil dilakukan (status pemrosesan Hold Counterparty Currency (HC)).

e) Transaksi-transaksi yang masih dalam Sistem Antrian (masih menunggu Penyelesaian Akhir).

2) Completed IFTS Enquiry

Fungsi ini digunakan untuk melihat rincian transaksi IFTS yang telah selesai. Transaksi–transaksi ini adalah:

a) Transaksi-transaksi yang telah dibatalkan oleh supervisor atau oleh RCC; dan

b) Transaksi-transaksi yang telah di-settle.

3) Warehouse IFTS Enquiry

Fungsi ini digunakan untuk melihat rincian transaksi yang akan diselesaikan pada tanggal valuta 1 (satu) atau 2 (dua) hari berikutnya (transaksi titipan/warehouse).

f. Batch

Batch merupakan proses akhir hari untuk persiapan awal hari kerja

c) Transaksi …


berikutnya. Proses batch hanya dapat dilakukan oleh user setingkat supervisor pada central department. Proses batch terdiri dari kegiatan:

1) Print End of Day Reports

Laporan-laporan akhir hari yang akan dicetak terdiri dari:

a) Incoming Message End of Day Listing

Merupakan laporan mengenai seluruh transaksi IFTS dan pesan-pesan administratif yang diterima dari RCC.

b) Outgoing Message End of Day Listing

Merupakan laporan mengenai seluruh transaksi IFTS dan pesan-pesan administratif yang dikirim ke RCC.

c) Daily Total Report

Merupakan laporan yang memuat rangkuman jumlah dan nilai dari semua transaksi IFTS dan pesan-pesan administratif yang dikirim dan diterima.

d) System Audit Trail

Merupakan rincian laporan yang memperlihatkan aktivitas-aktivitas pengguna Sistem BI-RTGS.

2) Back-up Daily Files

Fungsi ini merupakan fungsi yang digunakan untuk melakukan back-up harian terhadap files data RT ke dalam media penyimpanan pada waktu proses batch. Files yang di-back-up terdiri dari:

a) Transaction file;

b) Transaction history file;

c) Transaction image file;

d) WareHost transaction file;

e) WareHost transaction image file;

f) Account identifier file;

g) Member file;

h) System parameter file;

i) Member control file;

j) Department parameter file;

k) Department printer file;

l) Workstation parameter file;

m) User parameter file;

n) Transaction reference file;

o) System log file; dan

p) Communication log file.

3) Reset System Files

Fungsi ini digunakan untuk persiapan operasional hari berikutnya. Apabila seluruh file telah di-reset maka sistem telah siap untuk melaksanakan kegiatan hari kerja berikutnya. Jika reset file tidak

pesan-pesan …


dilakukan maka pada saat system start-up hari kerja berikutnya akan muncul error message.

g. Database

1) System Information

Merupakan fungsi yang digunakan untuk melihat dan mencetak informasi antara lain status Sistem BI-RTGS, cut-off time Sistem BI-RTGS, tanggal valuta terakhir, tanggal valuta sekarang dan tanggal valuta berikutnya.

2) Member Control File

Fungsi ini digunakan untuk mendefinisikan parameter yang berlaku bagi Peserta seperti:

a) IFTS Global Limit;

b) Password Expiry Period;

c) Inactive Period;

d) Timeout Interval;

e) Auto-refresh Interval;

f) PvP Notification Alert; dan

g) Print.

Perubahan terhadap data dalam file ini dilakukan setelah proses batch pada akhir hari oleh 2 (dua) user setingkat administrator.

3) Departement Parameter File

Fungsi ini digunakan untuk mendefinisikan parameter yang berlaku bagi departemen individual yang terdiri dari pendaftaran/penambahan, perubahan dan penghapusan. Setiap perubahan berlaku setelah mendapat persetujuan dari petugas lain yang berwenang. Penghapusan suatu departemen dilakukan setelah data workstation dan para user pada departemen tersebut dihapus.

4) Workstation Parameter File

Fungsi ini digunakan untuk mendefinisikan parameter mengenai workstation yang terdapat dalam RT yang terdiri dari pendaftaran/penambahan, perubahan dan penghapusan. Setiap perubahan terhadap parameter ini dilakukan selama Jam Operasional dan perubahan tersebut berlaku setelah mendapat persetujuan dari pejabat yang berwenang.

5) User Parameter File

Fungsi ini digunakan untuk mendefinisikan fungsi-fungsi setiap user yang terdiri dari pendaftaran/penambahan, perubahan dan penghapusan. File ini berisi:

a) Details;

b) Function Assignment;dan

c) Password Control.

BI-RTGS …


Untuk melakukan perubahan parameter ini user yang diubah harus melakukan sign-off terlebih dahulu. Setiap perubahan terhadap parameter ini dilakukan selama Jam Operasional. Penambahan dan perubahan user berlaku setelah mendapat persetujuan dari pejabat yang berwenang. Adapun persetujuan penghapusan user dilakukan setelah proses batch selesai.

6) Member File

Fungsi ini digunakan untuk menampilkan informasi dari semua Peserta yang berpartisipasi dalam Sistem BI-RTGS. Informasi ini disediakan oleh Penyelenggara. User hanya dapat melihat dan mencetak file ini tanpa kewenangan untuk mengubah. Apabila terdapat perubahan data Peserta maka member file tersebut akan di-update dari RCC. File ini berisi detil dari Peserta yang meliputi:

a) Member Code;

b) Member Name;

c) Bank Code;

d) BI Branch Code;

e) Member Type;

f) Member Group; dan

g) Principal Member.

7) PvP Member File

Fungsi ini digunakan untuk menampilkan informasi Peserta yang merupakan pengguna Mekanisme USD/IDR PvP pada Sistem BI-RTGS. Informasi ini disediakan oleh Penyelenggara. User hanya dapat melihat dan mencetak file ini tanpa kewenangan untuk mengubah. Apabila terdapat perubahan/penambahan data maka PvP member file tersebut akan di-update dari RCC. File ini berisi detil dari Peserta yang menggunakan fitur PvP dalam Sistem BI-RTGS:

a) PvP ID;

b) Participant Type;

c) Member Code; dan

d) Member Name.

Participation type dalam penggunaaan Mekanisme USD/IDR PvP pada Sistem BI-RTGS dikaitkan dengan kepesertaan Peserta pada USD CHATS dan dibedakan menjadi direct participant/DP dari USD CHATS (terisi: direct) dan indirect USD CHATS user/ICU (terisi: indirect). DP dari USD CHATS adalah Peserta yang merupakan bank peserta langsung dari USD CHATS, yang mempunyai rekening dalam mata uang Dolar Amerika Serikat yang ditatausahakan di penyelenggara/settlement institution (SI) dari USD CHATS. Sedangkan ICU dari USD CHATS adalah Peserta yang merupakan peserta tidak langsung dari USD CHATS, yang

6) Member …


mempunyai rekening dalam mata uang Dolar Amerika Serikat yang ditatausahakan di DP dari USD CHATS.

Member Code pada PvP Member File akan terisi kode Peserta dengan format menggunakan Bank Identifier Code (BIC) 11 digit yang dikeluarkan oleh Society for Worldwide Interbank Financial Telecommunication (SWIFT).

8) PvP Correspondent Member File

Fungsi ini digunakan untuk menampilkan informasi bank koresponden Dolar Amerika Serikat, yaitu DP dari USD CHATS atau SI dari USD CHATS, yang digunakan oleh Peserta untuk penyelesaian Transaksi PvP. Informasi ini disediakan oleh Penyelenggara. User hanya dapat melihat dan mencetak file ini tanpa kewenangan untuk mengubah. Apabila terdapat perubahan data maka PvP Correspondent Member File tersebut akan di-update dari RCC. File ini berisi detil bank koresponden Dolar Amerika Serikat dari Peserta pengguna USD/IDR PvP pada Sistem BI-RTGS.

PvP Correspondent Member Code pada PvP Correspondent Member File akan terisi kode bank koresponden Dolar Amerika Serikat dengan format menggunakan SWIFT BIC 11 digit.

9) Account Identifier Data (AID) File

Fungsi ini digunakan untuk menyimpan informasi nasabah-nasabah dari Peserta yang rutin melakukan transfer dana yang ditunjukkan dengan suatu nomor AID. Penggunaan AID ditujukan untuk mempermudah dan mempercepat pengisian data transfer. AID adalah suatu kode 6 (enam) karakter alfanumerik yang digunakan untuk mengidentifikasikan data-data nasabah atau rekening-rekening pemerintah atau rekening-rekening Bank Indonesia guna melaksanakan transaksi pengiriman dana (terdiri dari nomor rekening, nama rekening atau nama pemilik rekening, dan alamat pemilik rekening). AID tidak akan terbawa ke RCC (kecuali nomor rekening, nama rekening atau nama pemilik rekening yang terbentuk dari pemilihan suatu AID) melainkan merupakan database lokal RT Peserta.

Penambahan, perubahan dan penghapusan AID dilakukan selama Jam Operasional dan berlaku setelah mendapat persetujuan dari pejabat yang berwenang.

10) Transaction Reference File

Fungsi ini digunakan untuk menampilkan data Transaction Reference Number (TRN) yang ditetapkan oleh Penyelenggara. Perubahan terhadap file ini hanya dapat dilakukan oleh Penyelenggara. User hanya dapat melihat dan mencetak file ini tanpa kewenangan untuk mengubah. Apabila terdapat perubahan

8) PvP …


data TRN maka Transaction Reference File tersebut akan di-update dari RCC.

11) Authenticator Text (AT)

a) Authenticator Text File

AT adalah seperangkat text yang digunakan untuk mendapatkan encryption key melalui suatu algoritma otentikasi (authentication). Encryption key digunakan untuk encrypt dan decrypt log-on message yang dikirimkan dari RT ke RCC dan sebaliknya. 1 (satu) set AT terdiri dari 5 (lima) komponen AT (disebut AT 1 – AT 5), tanggal efektif dan kadaluarsa. Setiap komponen AT berisi sedikitnya 6 (enam) sampai dengan paling banyak 10 (sepuluh) karakter (alfanumerik). Satu set AT yang aktif (active set) adalah AT yang sedang digunakan untuk message authentication security antara RT dan RCC.

User dapat mengefektifkan reserved set untuk menggantikan active set pada setiap saat. Jika hal ini akan dilakukan, Peserta harus memberitahukan kepada Penyelenggara sebelum melakukan perubahan tersebut.

Setiap Peserta diharuskan memberikan komponen AT 1, AT 2 dan AT 3, sedangkan Penyelenggara akan memberikan komponen AT 4 dan AT 5. Satu set AT yang sama tidak dapat digunakan sampai dengan 3 (tiga) periode dari AT yang terdahulu. Jika terdapat suatu kesamaan (duplikasi), maka akan ditampilkan error message.

b) Generate AT Check Character

Fungsi ini digunakan untuk menghasilkan 1 (satu) karakter dari AT guna menghindari terjadinya kesalahan selama dilakukan data entry dari AT.

12) Print Control/Database Summary

Fungsi ini digunakan untuk mencetak files yang ada di database.

h. Utilities

Fungsi ini digunakan untuk melakukan kegiatan sebagai berikut:

1) Change Password

Fungsi ini digunakan oleh user untuk mengubah password jika diperlukan. Password yang sama dapat digunakan kembali oleh user setelah 3 (tiga) kali penggantian password.

2) Display/Print System Audit Trail

Merupakan kegiatan untuk menampilkan dan mencetak system audit trail.

3) Send Broadcast Message

otentikasi …


Fungsi ini digunakan oleh user yang sedang sign-on pada RT Server yang sama untuk mengirimkan administrative message.

4) Switch Printer

Fungsi ini digunakan oleh user untuk mengalihkan antrian cetakan dari satu printer ke printer lainnya.

5) IFTS Incoming Interface

Fungsi ini digunakan oleh user untuk melakukan transfer file standar yang telah ditetapkan dari Sistem BI-RTGS ke sistem internalnya.

6) IFTS Outgoing Interface

Fungsi ini digunakan oleh user untuk melakukan transfer file standar yang telah ditetapkan dari sistem internal ke Sistem BI-RTGS. Pengiriman ke RCC dilakukan setelah dilakukan proses persetujuan secara manual.

7) Auto IFTS Outgoing Interface

Fungsi ini digunakan oleh user untuk melakukan transfer file standar yang telah ditetapkan dari sistem internal ke Sistem BI-RTGS yang diikuti dengan pengiriman langsung ke RCC tanpa dilakukan proses persetujuan secara manual.

4. Pengoperasian dan Prosedur Pembukuan Transaksi Secara Umum

Prosedur umum pengoperasian Sistem BI-RTGS pada Peserta adalah sebagai berikut:

a. Administrator pada central department melakukan system start-up dan department start-up.

b. Supervisor pada central department melakukan log-on ke RCC

Kegiatan ini menghasilkan laporan log-on. Apabila log-on gagal akan muncul status penolakan disertai kode error dari RCC sebagaimana dimaksud pada Lampiran 3.1. Selanjutnya setelah diketahui penyebab kegagalannya, supervisor melakukan log-on kembali.

Apabila RT Peserta tetap tidak dapat log-on ke RCC melalui jaringan komunikasi data utama maka Peserta harus menghubungi help-desk Sistem BI-RTGS untuk meminta pengalihan jaringan komunikasi data utama menjadi jaringan komunikasi data back-up.

c. Selanjutnya setiap RT Workstation dapat melakukan pengiriman transaksi IFTS dan pesan-pesan administratif dengan proses sebagai berikut:

1) Peserta membuat dokumen/warkat sumber atau data elektronik sebagai dasar perekaman data transaksi. Format dokumen/warkat tersebut diatur oleh masing-masing Peserta.

2) Operator memasukkan password dan melakukan perekaman data transaksi antara lain dengan memasukkan data sebagai berikut:

5) IFTS …


a) Member Code Peserta pengirim;

b) Member Code Peserta penerima;

c) Tanggal valuta;

d) Jumlah nominal;

e) Related TRN (Rel TRN), merupakan referensi internal Peserta sehubungan dengan transaksi Sistem BI-RTGS;

f) Jenis transaksi berdasarkan TRN;

g) Nomor rekening, nama dan alamat pemberi amanat/rekening yang akan dibebani;

h) Nomor rekening, nama dan alamat penerima amanat/rekening yang akan menerima;

i) Payment detail, memuat keterangan mengenai transaksi seperti tujuan transaksi;

j) Member to member information;

k) Currency;

l) Exchange rate;

m) Interest rate;

n) Period; dan

o) Deal/stock code.

Perekaman data tersebut menghasilkan construct copy atau daftar IFTS outgoing summary transaction sebagai bukti perekaman telah dilakukan. Sistem BI-RTGS akan memberikan penomoran pada transaksi atau pesan yang dikirim ke Peserta lainnya (outgoing transaction) yang disebut dengan nomor BOR (Bank’s Own Reference). BOR terdiri dari 6 (enam) digit dan selalu dimulai dengan “000001” pada awal hari dengan nomor maksimum “999999” per hari. Nomor BOR ini akan di-reset setiap hari setelah batch akhir hari selesai dilakukan. Tata cara pengisian data perekaman tersebut di atas harus mengikuti prosedur sebagaimana dimaksud pada Lampiran 3.2.

Khusus untuk Transaksi PvP, disamping data sebagaimana dimaksud pada angka 2), operator juga harus melengkapi data pada Tab PvP Info yang akan muncul setelah operator memilih TRN: IFTPvP00. Data yang ada di Tab PvP Info tersebut meliputi:

a) Ordering Institution;

b) Beneficiary Institution;

c) Sender Correspondent;

d) Receiver Correspondent;

e) Counterparty (CP) Sender Correspondent;

f) Counterparty (CP) Receiver Correspondent;

g) Sender Nominal Amount; dan

Peserta …


h) Receiver Nominal Amount.

3) Supervisor dapat melakukan persetujuan, penolakan atau pembatalan transaksi yang telah di-input oleh operator. Dalam hal terdapat pembatasan kewenangan supervisor untuk melakukan approval maka terhadap transaksi yang nominalnya melebihi pembatasan yang ditetapkan harus dilakukan 2 (dua) tahap approval yaitu pre approval dan final approval.

a) Persetujuan

Supervisor melakukan persetujuan atas data transaksi yang di-construct oleh operator apabila data transaksi telah sesuai dengan dokumen/warkat sumber sebagai dasar perekaman data transaksi. Jika data transaksi yang di-transmit ke RCC telah sesuai dengan persyaratan pengiriman transaksi ke RCC (valid) maka status transaksi adalah AP AK (Approved Acknowledged) dan pada saat yang bersamaan akan menghasilkan transmit copy yang dapat dicetak. Jika data transaksi tidak valid pada saat di-transmit ke RCC maka status transaksi adalah AP NK (Approved Negative Acknowledgement). Jika transaksi telah diterima dan di-settle di RCC maka status transaksi adalah CP AK (Completed Acknowledged). Pada saat yang bersamaan dihasilkan completion advice yang dapat dicetak sedangkan Peserta penerima akan menerima confirmation advice.

Semua transaksi yang dikirim ke RCC akan diberikan nomor ISN oleh RCC, sedangkan untuk transfer yang diterima oleh Peserta dari RCC akan diberi nomor OSN oleh RCC. ISN dan OSN terdiri dari 6 (enam) digit (dimulai dari 000001 sampai dengan 999999) untuk masing-masing Peserta per hari. ISN dan OSN tersebut harus berpasangan untuk tujuan pengendalian urutan transaksi dan memastikan tidak terdapat transaksi yang hilang. ISN dan OSN akan di-reset setiap hari setelah batch processing hari sebelumnya telah dilaksanakan.

Khusus untuk Transaksi PvP yang valid dengan status AP AK (Approved Acknowledged), RCC akan meneruskan data Transaksi PvP tersebut ke IDR CCPMP untuk proses matching dengan data transaksi sisi mata uang Dolar Amerika Serikat pada USD CCPMP. RCC juga akan mengirimkan notifikasi kepada Peserta penerima pembayaran sisi mata uang Rupiah, yang berisikan informasi Transaksi PvP sebagaimana dimaksud pada angka 3) yang telah di-input pada Sistem BI-RTGS.

Status setelah pengiriman data Transaksi PvP ke IDR CCPMP adalah PM AK (Pending for Matching Acknowledged), dan akan menghasilkan PvP Pending for

pembatasan …


Matching advice. Setelah data Transaksi PvP diterima di IDR CCPMP maka proses selanjutnya adalah:

(1) IDR CCPMP dan USD CCPMP melakukan proses matching antara data Transaksi PvP pada IDR CCPMP dengan data transaksi sisi mata uang Dolar Amerika Serikat pada USD CCPMP. Adapun data yang digunakan untuk proses matching adalah sebagai berikut:

(a) Settlement date;

(b) Sender currency,

(c) Receiver currency;

(d) Ordering institution;

(e) Beneficiary institution;

(f) Sender amount;

(g) Receiver amount;

(h) Sender correspondent;

(i) Receiver correspondent;

(j) Counterparty sender correspondent; dan

(k) Counterparty receiver correspondent.

(2) Apabila data transaksi sisi mata uang Dolar Amerika Serikat pada USD CCPMP sebagaimana dimaksud pada angka (1) sama dengan data Transaksi PvP pada IDR CCPMP maka status Transaksi PvP berubah menjadi MT AK (PvP Matched Acknowledged) dan menghasilkan PvP Matched advice. Proses matching yang dilakukan pada CCPMP dilakukan berdasarkan prinsip First In First Out (FIFO);

(3) Apabila tidak ditemukan data yang sama antara data transaksi sisi mata uang Dolar Amerika Serikat pada USD CCPMP dengan data Transaksi PvP pada IDR CCPMP, maka status Transaksi PvP tetap PM AK (Pending for Matching Acknowledged);

(4) Selanjutnya, untuk Transaksi PvP dengan status MT AK (PvP Matched Acknowledged), saldo Rekening Giro Peserta pembayar sisi mata uang Rupiah di RCC akan di-hold sebesar nominal Transaksi PvP. Dalam hal saldo Rekening Giro Peserta pembayar sisi mata uang Rupiah di RCC mencukupi maka status Transaksi PvP menjadi HD AK (Hold IDR Fund Acknowledged) dan menghasilkan Hold Fund advice. Namun dalam hal saldo Rekening Giro Peserta pembayar sisi mata uang Rupiah tidak mencukupi maka Transaksi PvP akan

Serikat …


masuk ke dalam sistem antrian dan Transaksi PvP tersebut berstatus PH AK (Pending for Holding IDR Fund Acknowledged);

(5) Setelah berhasil dilakukan holding IDR fund di RCC dan selanjutnya berhasil pula dilakukan holding fund sisi mata uang Dolar Amerika Serikat di sistem komputer dari penyelenggara USD CHATS maka status Transaksi PvP menjadi HC AK (Hold Counterparty Currency Acknowledged), di mana selanjutnya akan dilakukan settlement sisi mata uang Rupiah di RCC dan settlement sisi mata uang Dolar Amerika Serikat di sistem komputer dari penyelenggara USD CHATS secara simultan. Proses settlement tersebut menghasilkan completion advice untuk Peserta pembayar sisi mata uang Rupiah, confirmation advice untuk Peserta penerima pembayaran sisi mata uang Rupiah, dan status Transaksi PvP menjadi CP AK (Completed Acknowledged).

b) Penolakan (reject amend)

Supervisor melakukan penolakan (reject amend) atas data transaksi yang di-construct oleh operator apabila data transaksi tidak sesuai dengan dokumen/warkat sumber sebagai dasar perekaman data transaksi. Pada saat yang bersamaan pada printer Peserta akan tercetak Reject Copy.

Untuk selanjutnya operator menyesuaikan data transaksi dengan dokumen/warkat sumber.

Status transaksi setelah reject amend adalah RJ NT (Reject Not Transmit).

c) Pembatalan (reject cancel)

Supervisor dapat melakukan pembatalan (reject cancel) atas data transaksi yang di-construct oleh operator. Pada saat yang bersamaan pada printer Peserta akan tercetak cancel copy.

Status transaksi setelah reject cancel adalah CA NT (Cancelled Not Transmit).

4) Kegiatan monitoring terhadap pelaksanaan pengiriman transaksi yang keluar dan masuk, termasuk melihat warehouse transaction dilakukan melalui menu “Enquiry” sebagai berikut:

a) Unfinished IFTS Enquiry

Dengan status : WA, RJ, AP, ED, SP, RD, NK, UP, PM, MT, PH, HD (uraian kode status sebagaimana tercantum pada Buku Pedoman Teknis Sistem BI-RTGS).

b) Completed IFTS Enquiry

sisi …


Dengan status: CA, CP, RH (uraian kode status pada Buku Pedoman Teknis Sistem BI-RTGS).

c) Warehouse IFTS Enquiry

Dengan status FD (Future Date) – Tanggal yang akan datang.

Buku Pedoman Teknis Sistem BI-RTGS tersebut disampaikan kepada Peserta secara terpisah dari Surat Edaran ini.

5) Untuk kepentingan pengambilan keputusan supervisor dan administrator dapat melihat data-data yang diperlukan melalui menu “Supervisory”.

6) Apabila diperlukan, administrator dan supervisor dapat memonitor seluruh aktivitas yang terjadi melalui RT, melalui menu “Audit Trail”.

7) Selama Jam Operasional, supervisor dimungkinkan untuk mengambil data transaksi dari RCC dan mencetaknya pada printer Peserta untuk transaksi tanggal valuta terakhir dan valuta sekarang dengan key nomor ISN/OSN masing-masing transaksi. Retrieval data transaksi dilakukan dengan tata cara sebagai berikut:

a) Peserta harus mengajukan permintaan ISN/OSN kepada Penyelenggara melalui fasilitas telepon. Selain itu dimungkinkan untuk mencetak laporan ringkas per Peserta dan rincian incoming transfer dan outgoing transfer;

b) Penyelenggara memberikan nomor ISN/OSN melalui fasilitas telepon;

c) Peserta melakukan retrieval transaksi melalui RT oleh user setingkat supervisor atau administrator.

8) RT dapat mengirimkan pesan-pesan administratif kepada RT lainnya dan RCC. Pengiriman transaksi ini dilakukan oleh 2 (dua) user setingkat supervisor atau administrator.

9) Pada akhir hari setelah Peserta menyelesaikan seluruh transaksi, dilakukan hal–hal sebagai berikut:

a) supervisor pada central department melakukan log-off dari RCC;

b) user setingkat administrator melakukan department shut-down;

c) user setingkat administrator melakukan system shut-down; dan

d) supervisor melakukan batch akhir hari.

5. Transaksi dengan Pengaturan Khusus

Beberapa transaksi Sistem BI-RTGS perlu diatur khusus mekanisme pelaksanaannya sebagai berikut:

a. Transaksi Pasar Uang Antar Bank Rupiah tidak mempersyaratkan pengiriman bukti transaksi seperti promes atau dokumen lainnya kepada

Buku …


Penyelenggara.

b. Transaksi penarikan tunai

1) Pelaksanaan pembukuan transaksi penarikan tunai mengacu pada Jam Operasional Sistem BI-RTGS sebagaimana dimaksud pada Lampiran 3.3.

2) Batas waktu transfer penarikan tunai dalam Sistem BI-RTGS sampai dengan pukul 11.00 WIB. Pengambilan fisik uang harus memperhatikan jam pelayanan loket kas masing-masing kantor Bank Indonesia. Dalam hal sampai dengan jam pelayanan loket kas berakhir Peserta belum melakukan pengambilan fisik uang maka Bank Indonesia akan mengembalikan dana tersebut ke Rekening Giro Rupiah Peserta yang bersangkutan.

3) Pengambilan fisik uang dilakukan dengan menyerahkan surat penunjukan pengambilan fisik uang yang ditandatangani oleh pejabat atau petugas yang berwenang dan telah memiliki spesimen tanda tangan di unit kerja kas KPBI atau unit kerja yang membawahi layanan nasabah di KBI. Format surat penunjukan sebagaimana dimaksud pada Lampiran 3.4.

4) Pengambilan fisik uang dilakukan oleh petugas yang diberi kuasa oleh Direksi atau oleh pejabat lain yang menerima kuasa khusus dengan hak substitusi dari Direksi dengan ketentuan sebagai berikut:

a) KPBI

Petugas yang bersangkutan harus telah didaftarkan dalam sistem antrian penarikan uang tunai (queue management system) di unit kerja kas di KPBI.

b) KBI

Petugas harus memiliki spesimen tanda tangan di KBI yang bersangkutan.

c. Transaksi dengan Pemerintah sebagai nasabah Bank Indonesia

1) Pembukuan Transaksi

Pembukuan transaksi yang ditujukan untuk rekening pemerintah dapat dilakukan setelah RCC buka sampai dengan jam tutup TRN.

Hal-hal yang terkait dengan pembukuan transaksi pelimpahan setoran penerimaan negara melalui Sistem BI-RTGS tersebut adalah sebagai berikut:

a) Pelimpahan setoran penerimaan negara dilakukan melalui RT Peserta untuk untung rekening Sub RKUN Kantor Pelayanan Perbendaharaan Negara (KPPN) di KPBI atau KBI.

b) Pelaksanaan pelimpahan melalui Sistem BI-RTGS dibatasi paling lambat pukul 16.30 WIB.

c) Bukti setoran atas pelimpahan ke rekening Sub RKUN KPPN

Lampiran …


adalah:

(1) Bukti setoran terdiri dari completion advice yang tercetak pada Peserta yang ditandatangani oleh pejabat Peserta atau re-print confirmation advice yang tercetak di Bank Indonesia dan dibubuhi stempel tandatangan pejabat Bank Indonesia setempat.

(2) Jika kantor Peserta yang melakukan penyetoran merupakan pengelola RT Server maka bukti setoran berupa completion advice.

(3) Jika kantor Peserta yang melakukan penyetoran bukan merupakan pengelola RT Server maka bukti setoran bagi kantor Peserta tersebut berupa re-print confirmation advice yang diambil di Bank Indonesia setempat.

d) Apabila terjadi kekurangan/kelebihan jumlah dana yang dilimpahkan dan/atau terjadi kesalahan penulisan kantor Bank Indonesia yang dituju maka Peserta dapat meminta pengembalian dana kepada kantor Bank Indonesia penerima dana yang salah tersebut sesuai dengan mekanisme koreksi sebagaimana dimaksud dalam Bab VI.

2) Transaksi dalam rangka pelaksanaan Treasury Single Account (TSA)

Mekanisme dan penetapan biaya transaksi dalam rangka pelaksanaan TSA dilakukan sesuai dengan ketentuan Bank Indonesia yang mengatur mengenai penetapan biaya penggunaan Sistem BI-RTGS dalam rangka penerapan TSA.

d. Transaksi PvP

1) Transaksi PvP hanya dapat dilakukan oleh Peserta yang telah terdaftar sebagai pengguna Mekanisme USD/IDR PvP.

2) Penyelesaian akhir Transaksi PvP mengikuti proses sebagaimana dimaksud pada butir 4.c.

3) Transaksi PvP hanya dapat dilakukan sepanjang Sistem BI-RTGS dan USD CHATS beroperasi. Disamping itu pengiriman Transaksi PvP hanya dapat dilakukan sepanjang window time PvP. Dalam hal Peserta mengirimkan Transaksi PvP diluar window time PvP atau pada saat sistem USD CHATS tidak beroperasi/libur maka transaksi tersebut ditolak oleh RCC, berstatus RH (Rejected by Host) dan tercetak Completion Advice.

6. Fasilitas warehouse dalam Sistem BI-RTGS

Untuk transaksi yang dikirim ke RCC dengan tanggal valuta T+1 dan T+2, jika data transaksi valid maka transaksi tersebut disimpan di warehouse database RCC. Pada saat tanggal valuta jatuh tempo maka transaksi akan di-settle pada awal hari oleh RCC. Dalam hal saldo tidak mencukupi, transaksi tersebut

di …

(settlement …


masuk dalam Sistem Antrian dengan tingkat kepentingan sesuai dengan jenis transaksi/TRN. Untuk Transaksi PvP, pada tanggal valuta jatuh tempo maka transaksi akan dikirimkan ke IDR CCPMP untuk dilakukan proses sebagaimana dimaksud pada butir 4.c. Waktu pengiriman transaksi warehouse (settlement dengan tanggal valuta T+1 atau T+2) adalah sesuai dengan window time masing-masing jenis transaksi sebagaimana dimaksud pada Lampiran 3.3.

7. Jam Operasional

Penyelenggaraan Sistem BI-RTGS dilaksanakan setiap hari kerja kecuali ditetapkan lain oleh Penyelenggara. Kegiatan selama Jam Operasional adalah sebagai berikut:

a. Sejak RCC open sampai dengan cut off warning

1) Transaksi-transaksi melalui Sistem BI-RTGS yang dapat dilakukan dalam periode ini meliputi transaksi sebagaimana dimaksud pada Lampiran 3.3. Pelaksanaan pengiriman transaksi melebihi waktu yang telah ditetapkan secara otomatis akan ditolak oleh RCC.

2) Transaksi PvP hanya dapat dilakukan dalam periode antara PvP open sampai dengan PvP cut off. Dalam periode ini terdapat beberapa kegiatan sebagai berikut:

a) RT masing-masing Peserta secara periodik menampilkan notifikasi berupa pop up message yang berisi Transaksi PvP masing-masing Peserta yang masih outstanding (status Pending for Matching (PM), PvP Matched (MT), Pending for Holding IDR Funds (PH), dan Hold IDR Fund (HD)).

b) Pada saat PvP cut off warning, RCC mengirimkan notifikasi berupa pop up message yang berisi Transaksi PvP masing-masing Peserta yang masih outstanding dan Peserta menerima PvP outstanding report.

c) Pada saat PvP cut off, semua transaksi yang masih outstanding ditolak oleh RCC (status pemrosesan menjadi Rejected by Host (RH)) dan Peserta menerima PvP cut off position report.

b. Waktu antara cut off warning sampai dengan pre cut off

Dalam periode ini terdapat beberapa kegiatan sebagai berikut:

1) RCC secara otomatis melakukan special gridlock resolution, yaitu menyelesaikan seluruh antrian Peserta berdasarkan kecukupan dana masing-masing transaksi.

2) Pada saat cut off warning:

a) Peserta menerima:

(1) “cut off warning report”, yang memuat informasi waktu pelaksanaan cut off warning; dan

(2) “Pre Cover Position report”, yang memuat informasi posisi saldo Rekening Giro Peserta.


b) Transaksi yang masuk ke dalam Sistem Antrian akan ditolak secara otomatis oleh RCC sedangkan transaksi yang masih dalam Sistem Antrian akan dibatalkan secara otomatis oleh RCC. Atas transaksi yang dibatalkan, Peserta pengirim akan menerima completion advice dengan reason code tertentu.

3) Peserta diberikan kesempatan untuk melakukan transfer antar Peserta dalam rangka menutupi kekurangan likuiditas (Interbank Cover Position).

c. Waktu antara pre cut off sampai dengan cut off (BI Cover Position)

1) Dalam hal Peserta diberikan fasilitas pendanaan oleh Bank Indonesia, maka pengkreditan Rekening Giro Peserta dilakukan pada periode ini.

2) Pada saat pre cut off, Peserta menerima pre cut off notification report dan member reconciliation report.

d. Waktu RCC cut off

Pada waktu RCC cut off, seluruh transaksi yang dikirimkan melalui RT akan ditolak secara otomatis oleh RCC. Pada saat cut off, Peserta menerima cut off notification report, cut off position report dan member statement.

Rincian kegiatan dan Jam Operasional pada huruf a sampai dengan huruf d sebagaimana dimaksud pada Lampiran 3.3. Penetapan waktu yang menjadi acuan dalam Jam Operasional tersebut adalah waktu di RCC.

8. Perubahan Jam Operasional

Perubahan Jam Operasional dilakukan atas dasar kebijakan Penyelenggara dan dapat berupa perpanjangan atau pengurangan Jam Operasional.

a. Perpanjangan Jam Operasional dilakukan dalam hal terjadi:

1) Gangguan atau kerusakan pada RCC;

2) Keterlambatan waktu Penyelesaian Akhir hasil kliring;

3) Adanya kebijakan yang menyebabkan Penyelenggara harus memperpanjang Jam Operasional, antara lain adanya permintaan pemerintah dalam rangka pembayaran pajak, untuk kepentingan Bank Indonesia dalam pelaksanaan kebijakan moneter atau adanya gangguan pada jaringan komunikasi yang menghubungkan RCC dengan RT Peserta dan/atau yang menghubungkan RCC dengan infrastruktur teknologi informasi Mekanisme USD/IDR PvP di Hong Kong; atau

4) Adanya permintaan perpanjangan window time TRN dari Peserta yang berdampak pada perubahan Jam Operasional.

b. Pengurangan Jam Operasional dilakukan dalam hal tidak terdapat lagi transaksi yang masih harus diselesaikan.

c. Khusus untuk transaksi penarikan tunai, pelimpahan pajak, dan Transaksi PvP, dalam hal terjadi perpanjangan atau pengurangan Jam Operasional maka tidak selalu diikuti dengan perpanjangan atau pengurangan window

menerima …


time ketiga transaksi tersebut.

d. Perubahan Jam Operasional akan diinformasikan kepada seluruh Peserta melalui fasilitas administrative message.

9. Permintaan Perpanjangan Window Time TRN oleh Peserta

Permintaan perpanjangan window time TRN oleh Peserta dilakukan dengan ketentuan sebagai berikut:

a. Permintaan dapat diajukan oleh Peserta apabila terdapat gangguan pada Peserta.

b. Permintaan diajukan kepada Penyelenggara melalui fasilitas administrative message yang ditujukan ke RCC atau sarana lainnya dengan menjelaskan kondisi gangguan yang telah terjadi di Peserta, dan telah didahului dengan konfirmasi melalui telepon.

c. Permintaan diajukan paling lambat 30 (tiga puluh) menit sebelum berakhirnya window time TRN yang dimintakan perpanjangan.

d. Permintaan perpanjangan window time TRN tidak dapat diajukan untuk transaksi penarikan tunai, pelimpahan pajak dan/atau Transaksi PvP.

e. Penggunaan sarana lain untuk mengajukan perpanjangan window time TRN sebagaimana dimaksud pada huruf b dilakukan dengan tata cara sebagai berikut:

1) Peserta yang berkantor pusat di wilayah kerja KPBI

Peserta menyampaikan surat permintaan perpanjangan window time TRN kepada Penyelenggara yang ditandatangani oleh pejabat yang memiliki spesimen tanda tangan di Penyelenggara.

2) Peserta yang berkantor pusat di wilayah kerja KBI

a) dalam hal jam kerja KBI setempat belum berakhir maka Peserta menyampaikan surat permintaan perpanjangan window time TRN kepada KBI setempat yang ditandatangani oleh pejabat yang memiliki tanda tangan di KBI setempat.

b) dalam hal jam kerja KBI setempat telah berakhir maka Peserta menyampaikan surat permintaan perpanjangan window time TRN kepada Penyelenggara yang ditandatangani oleh Direksi yang memiliki spesimen tanda tangan di Penyelenggara melalui faksimili. Pada hari kerja berikutnya, asli surat disampaikan kepada KBI setempat untuk diteruskan kepada Penyelenggara.

f. Dalam hal permintaan perpanjangan window time TRN disetujui, Penyelenggara akan memperpanjang window time TRN yang masih terbuka pada saat permintaan perpanjangan diterima oleh Penyelenggara secara proporsional sesuai dengan permintaan Peserta.

Contoh: Pada pukul 16.00 WIB terdapat persetujuan perpanjangan window time TRN selama 30 (tiga puluh) menit. Sehubungan dengan hal itu:

9. Permintaan …


1) seluruh TRN yang window time-nya belum berakhir diperpanjang selama 30 (tiga puluh) menit, misalnya TRN IFT00000 yang seharusnya berakhir pada pukul 16.30 WIB menjadi berakhir pada pukul 17.00 WIB dan untuk TRN IFTMM001 yang seharusnya berakhir pada pukul 18.00 WIB menjadi berakhir pada pukul 18.30 WIB; dan

2) berdasarkan disetujuinya perpanjangan window time tersebut, Penyelenggara memperpanjang Jam Operasional secara proporsional.

g. Perpanjangan window time TRN yang dapat diberikan Bank Indonesia yaitu selama 30 (tiga puluh) menit atau 60 (enam puluh) menit.

h. Dalam hal telah terdapat Peserta yang mengajukan perpanjangan window time TRN selama 60 (enam puluh) menit maka Peserta lain tidak dapat mengajukan perpanjangan window time TRN.

i. Persetujuan atau penolakan atas permohonan perpanjangan window time TRN disampaikan oleh Penyelenggara kepada Peserta melalui fasilitas administrative message atau, apabila terdapat gangguan pada RT Server Peserta, melalui sarana lainnya.

j. Permintaan perpanjangan window time TRN yang disetujui Penyelenggara akan diinformasikan kepada seluruh Peserta melalui fasilitas administrative message.

k. Atas perpanjangan window time TRN yang disetujui, Peserta dikenakan biaya yang besarnya akan diumumkan Penyelenggara. Biaya tersebut akan dibebankan secara langsung oleh Bank Indonesia ke Rekening Giro Peserta paling lambat pada hari kerja berikutnya.

l. Setiap permintaan perpanjangan window time TRN yang telah disetujui oleh Penyelenggara tidak dapat dibatalkan oleh Peserta yang bersangkutan.

10. Libur Fakultatif

Dalam hal daerah tertentu ditetapkan libur secara fakultatif berlaku ketentuan sebagai berikut:

a. Penyelenggara mengumumkan libur fakultatif tersebut melalui fasilitas administrative message kepada seluruh Peserta yang menginformasikan bahwa kantor Bank Indonesia dan Peserta yang berada di wilayah kerja kantor Bank Indonesia tersebut tidak melakukan kegiatan operasional Sistem BI-RTGS.

b. Dalam hal Peserta yang berada di luar wilayah kantor Bank Indonesia yang ditetapkan libur fakultatif mengirimkan transaksi kepada kantor Bank Indonesia yang ditetapkan libur fakultatif maka berlaku ketentuan sebagai berikut:

1) Penyelesaian transaksi yang ditujukan ke rekening pemerintah atau rekening internal BI dilakukan pada hari kerja berikutnya.

2) Untuk transaksi penarikan tunai akan dikembalikan ke rekening

pukul …


Peserta pengirim oleh Penyelenggara pada hari yang sama.

11. Hal-hal yang harus dilakukan Penyelenggara dan Peserta dalam penyelenggaraan Sistem BI-RTGS

a. Penyelenggara

Dalam rangka penyelenggaraan Sistem BI-RTGS, Penyelenggara melakukan hal-hal sebagai berikut:

1) Menyediakan sarana dan prasarana penyelenggaraan Sistem BI-RTGS

Penyediaan sarana dan prasarana Sistem BI-RTGS oleh Penyelenggara meliputi penyediaan perangkat keras (hardware) pada Penyelenggara, aplikasi RCC (software), jaringan komunikasi data leased line, fasilitas dial up dan perangkat pendukung lainnya termasuk untuk pelaksanaan mekanisme USD/IDR PvP pada Sistem BI-RTGS.

2) Menjamin RCC, jaringan komunikasi data leased line, dan fasilitas dial up berfungsi dengan baik

Dalam rangka menjamin RCC, jaringan komunikasi data leased line, dan fasilitas dial up agar dapat berfungsi dengan baik, Penyelenggara melakukan:

a) Pengelolaan RCC

Kegiatan pengelolaan RCC antara lain meliputi:

(1) penentuan petugas yang berhak mengoperasikan RCC;

(2) mengelola database RCC; dan

(3) mengelola dan menetapkan parameter RCC.

b) Pengoperasian RCC

Kegiatan pengoperasian RCC meliputi:

(1) proses awal hari;

(2) proses operasional; dan

(3) proses akhir hari.

c) Pengelolaan jaringan komunikasi data leased line dan fasilitas dial up

Pengelolaan jaringan komunikasi data leased line dan fasilitas dial up dilakukan antara lain dengan menyediakan petugas help desk untuk membantu apabila terjadi permasalahan jaringan komunikasi data leased line Peserta dan mengelola fasilitas dial up yang digunakan sebagai jaringan komunikasi data back up.

d) Meletakkan RCC dalam ruangan tertutup dengan akses terbatas pada pegawai-pegawai yang berwenang untuk menggunakan RCC.

e) Melakukan pembatasan nilai nominal transaksi melalui

a. Penyelenggara …


Sistem BI-RTGS, apabila diperlukan.

Penyelenggara mengumumkan pembatasan minimum nilai nominal transaksi dan waktu berlakunya pembatasan tersebut kepada Peserta sebelum pelaksanaan pembatasan dimaksud.

f) Memiliki standar layanan minimum penyelenggaraan Sistem BI-RTGS.

3) Melakukan konsultasi dengan satuan kerja di Bank Indonesia yang berwenang melakukan pengawasan terhadap penyelenggaraan sistem pembayaran sesuai dengan ketentuan internal Bank Indonesia.

4) Memiliki pedoman Disaster Recovery Plan (DRP) atau Business Continuity Plan (BCP).

5) Menyediakan jaringan komunikasi data leased line yang menghubungkan RT Server Utama atau RT Server Back-up dengan RCC Utama atau RCC Back-up.

Penyelenggara hanya menyediakan 1 (satu) jaringan komunikasi data leased line yang menghubungkan RT Server Utama atau RT Server Back-up dengan RCC Utama atau RCC Back-up. Dalam hal Peserta menambah jaringan komunikasi data selain yang disediakan Penyelenggara, maka biaya penambahan penyediaan dan penggunaaan jaringan komunikasi data dimaksud menjadi beban Peserta. Jenis dan penggunaan jaringan komunikasi data tersebut disesuaikan dengan standar yang ditetapkan dan memperoleh persetujuan dari Penyelenggara.

6) Menyediakan aplikasi RT dan perubahannya

Dalam hal terjadi perubahan aplikasi RT, maka Penyelenggara akan mengirimkan aplikasi RT terbaru beserta pedoman instalasinya kepada seluruh Peserta.

7) Melakukan pemantauan terhadap:

a) Keberhasilan akses komunikasi RT Peserta dengan RCC;

b) Keberhasilan akses komunikasi antara RCC dengan infrastruktur teknologi informasi lainnya dari USD/IDR PvP seperti IDR CCPMP dan USD CCPMP; dan

c) Kecukupan saldo Rekening Giro Peserta di Bank Indonesia pada akhir hari.

8) Menyediakan help desk untuk menangani masalah operasional Sistem BI-RTGS yang dihadapi Peserta.

9) Memberikan pelayanan yang berkaitan dengan kepesertaan dalam Sistem BI-RTGS, yang antara lain meliputi:

a) Pendaftaran kepesertaan dalam Sistem BI-RTGS; dan

b) Perubahan kepesertaan dalam Sistem BI-RTGS, meliputi antara lain:

kepada …


(1) Perubahan dari Peserta Tidak Langsung menjadi Peserta Langsung atau sebaliknya;

(2) Keikutsertaan dalam Mekanisme USD/IDR PvP;

(3) Merger, Konsolidasi, atau Pemisahan;

(4) Perubahan bank koresponden dari Peserta pengguna Mekanisme USD/IDR PvP;

(5) Perubahan member code;

(6) Perubahan nama;

(7) Perubahan alamat;

(8) Perubahan kegiatan usaha Bank dari konvensional menjadi syariah; dan

(9) Perubahan status kepesertaan menjadi suspend, freeze atau close.

10) Memberikan pelatihan kepada calon Peserta dan pelatihan secara berkala kepada Peserta.

11) Memastikan bahwa penyedia jasa yang terkait dengan penyelenggaraan Sistem BI-RTGS melaksanakan kewajibannya untuk menjaga kelangsungan operasional Sistem BI-RTGS sesuai dengan Service Level Agreement (SLA) yang telah ditetapkan dalam kontrak antara Penyelenggara dengan penyedia jasa.

b. Peserta

1) Dalam rangka penyelenggaraan Sistem BI-RTGS, Peserta Langsung dan Peserta Tidak Langsung wajib:

a) menggunakan TRN sesuai dengan peruntukannya dan memenuhi tata cara pengisian informasi TRN yang ditetapkan oleh Penyelenggara yang disampaikan kepada Peserta melalui administrative message, surat atau sarana lain.

b) menggunakan aplikasi RT sesuai dengan Buku Pedoman Teknis Sistem BI-RTGS yang disampaikan Penyelenggara kepada Peserta secara terpisah dari Surat Edaran ini.

c) mengatur kewenangan penggunaan aplikasi RT, termasuk menyimpan dan menjaga kerahasiaan password penggunaan aplikasi RT.

d) memelihara dan menyimpan dengan baik password administrator Structured Query Language (SQL) database untuk database SQL pada RT Server Utama dan/atau RT Server Back-up.

e) melakukan instalasi setiap terjadi perubahan aplikasi RT yang disampaikan oleh Penyelenggara sesuai dengan prosedur yang telah ditetapkan.

f) menyimpan dengan baik aplikasi RT yang telah diberikan oleh Penyelenggara, termasuk setiap terdapat versi baru di

(3) Merger, …


tempat yang aman dan bebas dari berbagai sumber yang dapat merusak aplikasi RT.

g) menjamin integritas database Sistem BI-RTGS yang ada pada RT Server Utama dan RT Server Back-up termasuk yang disimpan untuk back-up dalam bentuk Compact Disk (CD), tape, cartridge, disket dan lain-lain.

h) menyimpan seluruh data elektronik transaksi pembayaran sesuai dengan jangka waktu yang ditetapkan dalam ketentuan yang mengatur dokumen perusahaan.

i) memberikan informasi yang diminta oleh Penyelenggara dalam rangka konfirmasi kepatuhan Peserta pada ketentuan yang ditetapkan oleh Bank Indonesia baik sebagai regulator maupun Penyelenggara, dan Perjanjian Penggunaan Sistem BI-RTGS antara Penyelenggara dan Peserta.

2) Dalam rangka penyelenggaraan Sistem BI-RTGS, Peserta Langsung wajib:

a) menjamin RT Server Utama, RT Server Back-up dan RT Workstation berfungsi dengan baik.

RT Server Utama dan RT Workstation dikatakan berfungsi dengan baik apabila perangkat keras (hardware) dan perangkat lunak (software) di dalamnya dapat digunakan untuk melakukan berbagai transaksi sepanjang Jam Operasional Sistem BI-RTGS. RT Server Back-up dikatakan berfungsi dengan baik apabila perangkat keras (hardware) dan perangkat lunak (software) di dalamnya dapat digunakan menggantikan RT Server Utama untuk melakukan transaksi sewaktu-waktu apabila diperlukan.

Terkait dengan RT Server Back-up berlaku ketentuan sebagai berikut:

(1) RT Server Back-up sekurang-kurangnya dilengkapi dengan 1 (satu) RT Workstation serta 1 (satu) printer.

Berdasarkan konfigurasi sistem back-up dan proses up-dating datanya, RT Server Back-up dapat dibedakan menjadi:

(a) Hot back-up

Hot back-up adalah sistem teknologi informasi cadangan dengan karakteristik:

i. sudah dipasang dengan aplikasi yang sama dengan aplikasi pada RT Server Utama;

ii. terhubung langsung dengan RT Server Utama (online); dan

iii. up-dating data dilakukan setiap saat

pada …


bersamaan dengan up-dating data pada RT Server Utama (synchronised).

(b) Warm back-up

Warm back-up adalah sistem teknologi informasi cadangan dengan karakteristik:

i. sudah dipasang dengan aplikasi yang sama dengan aplikasi pada RT Server Utama; dan

ii. up-dating data dan aplikasi dilakukan secara berkala, sehingga kepindahan ke RT Server Back-up mensyaratkan proses restore untuk menyamakan data di RT Server Back-up dengan posisi terakhir di RT Server Utama.

(c) Cold back-up

Cold back-up adalah sistem teknologi informasi cadangan yang tidak terhubung langsung dengan RT Server Utama sehingga pada saat akan menggunakan RT Server Back-up diperlukan tahapan untuk mengaktifkan RT Server Back-up, dan restore data untuk menyamakan data di RT Server Back-up dengan RT Server Utama. Untuk menjamin kesiapan RT Server Back-up Peserta harus melakukan proses up-dating data sekurang-kurangnya 1 (satu) kali sehari pada setiap akhir hari.

(2) Pemilihan konfigurasi back-up yang ada pada Peserta diserahkan kepada setiap Peserta berdasarkan pertimbangan tingkat urgensi Sistem BI-RTGS bagi Peserta.

(3) RT Server Back-up dapat diletakkan pada lokasi yang sama dengan RT Server Utama (on-site back-up) ataupun diletakkan di lokasi yang berbeda dengan RT Server Utama (off-site back-up). Untuk menjamin kelangsungan operasional Sistem BI-RTGS, masing-masing Peserta sebaiknya memiliki off-site back-up. Di samping itu, RT Server Back-up sebaiknya ditempatkan di lokasi yang jaringan komunikasinya berada di bawah Sentral Telepon Otomat (STO) yang berbeda dengan RT Server Utama.

(4) Untuk menjamin RT Server Back-up dapat berfungsi dengan baik, Peserta dapat melakukan uji coba koneksi RT Server Back-up dengan tata cara sebagai berikut:

(b) Warm …


(a) Peserta menyampaikan permohonan uji coba koneksi RT Server Back-up melalui fasilitas administrative message atau surat kepada Penyelenggara. Jadwal uji coba koneksi RT Server Back-up dilaksanakan setiap bulan pada hari Senin minggu pertama dan minggu ketiga.

(b) pemberitahuan persetujuan uji coba koneksi RT Server Back-up akan diberitahukan oleh Penyelenggara kepada Peserta melalui sarana administrative message

(c) pelaksanaan uji coba koneksi RT Server Back-up akan dipantau oleh petugas dari Penyelenggara sampai 1 (satu) jam sejak proses akhir hari RCC berakhir.

(5) Untuk menjamin data back-up dapat dibaca kembali, Peserta melakukan uji coba restore data back-up.

b) Mengoperasikan RT Server Back-up sewaktu-waktu untuk kegiatan operasional dalam kondisi normal.

Kegiatan ini dimaksudkan untuk menjamin dapat dioperasikannya RT Server Back-up apabila terjadi gangguan pada RT Server Utama.

Prosedur pengoperasian RT Server Back-up:

(1) Peserta menyampaikan permohonan penggunaan RT Server Back-up melalui fasilitas administrative message ke RCC atau surat yang ditujukan kepada Penyelenggara;

(2) pemberitahuan persetujuan pengunaan RT Server Back-up dan prosedur yang harus dilakukan oleh Peserta akan diberitahukan oleh Penyelenggara kepada Peserta melalui sarana administrative message; dan

(3) pelaksanaan penggunaan RT Server Back-up dipantau oleh Penyelenggara sampai 1 (satu) jam sejak proses akhir hari RCC berakhir.

c) Menyusun Kebijakan dan Prosedur Tertulis (KPT) yang mendukung sistem kontrol internal yang baik dalam pelaksanaan operasional Sistem BI-RTGS.

Penyusunan KPT ini harus dibuat dalam Bahasa Indonesia atau dalam bahasa asing dengan terjemahan dalam Bahasa Indonesia yang mengacu pada dan tidak bertentangan dengan Surat Edaran ini serta mengacu kesepakatan tertulis antar Peserta (Bye-Laws). KPT dimaksud sekurang-kurangnya memuat materi sebagai berikut:

(1) Struktur organisasi satuan kerja pelaksana Sistem BI-

Penyelenggara …


RTGS;

(2) Penanggungjawab Sistem BI-RTGS;

(3) Wewenang pengoperasian Sistem BI-RTGS;

(4) Sistem pengamanan, (seperti sistem pengamanan aplikasi);

(5) Prosedur pengoperasian dan pembukuan transaksi Sistem BI-RTGS;

(6) Prosedur operasional transaksi treasury;

(7) Pengawasan operasional Sistem BI-RTGS; serta

(8) Prosedur Contingency Plan.

Rincian cakupan minimum materi diatur dalam “Pedoman Penyusunan Kebijakan dan Prosedur Tertulis” sebagaimana dimaksud pada Lampiran 3.5.

Khusus untuk Peserta Langsung yang menyediakan RT untuk digunakan oleh Peserta Tidak Langsung, KPT tersebut juga harus memuat materi sebagaimana dimaksud pada angka (1) sampai dengan angka (8) yang diterapkan pada Peserta Tidak Langsung.

d) KPT sebagaimana dimaksud pada huruf c) dan setiap perubahannya disampaikan dalam bentuk hardcopy dengan surat pengantar yang ditandatangani oleh Direktur Kepatuhan (khusus bagi Bank sebagai Peserta) atau direktur yang membawahi satuan kerja pengawasan intern (khusus bagi Pihak Selain Bank sebagai Peserta) kepada:

Direktorat Akunting dan Sistem PembayaranBagian Penyelenggaraan Setelmen Bank IndonesiaGedung D Lantai 3Jalan MH. Thamrin No. 2 Jakarta 10350

KPT disampaikan paling lambat 6 (enam) bulan sejak kepesertaan dalam Sistem BI-RTGS dan setiap perubahan disampaikan paling lambat 1 (satu) bulan terhitung sejak terjadinya perubahan. Perubahan yang wajib disampaikan adalah perubahan yang mendasar terhadap operasional Sistem BI-RTGS.

e) Melakukan pemeriksaan internal yang menjamin keamanan operasional Sistem BI-RTGS sekurang-kurangnya 1 (satu) kali dalam setahun.

Pelaksanaan pemeriksaan internal ini wajib dilakukan dengan mengacu pada dan tidak bertentangan dengan Surat Edaran ini, kesepakatan tertulis antar Peserta (Bye-Laws) dan paling kurang mencakup ruang lingkup pemeriksaan internal sebagaimana diatur dalam Lampiran 3.6.

(4) Sistem …


Khusus untuk Peserta Langsung yang menyediakan RT bagi Peserta Tidak Langsung, pemeriksaan internal tersebut mencakup pula pemeriksaan internal pada Peserta Tidak Langsung dengan ruang lingkup yang sama pada Lampiran 3.6.

f) Menyampaikan laporan hasil pemeriksaan internal sebagaimana dimaksud pada huruf e).

Laporan hasil pemeriksaan internal yang disampaikan berupa ringkasan hasil pemeriksaan internal yang dilakukan oleh Peserta, antara lain berupa temuan, tanggapan auditee dan rekomendasi hasil pemeriksaan internal. Penyampaian laporan hasil pemeriksaan internal dilakukan dengan surat pengantar yang ditandatangani oleh Direktur Kepatuhan (khusus bagi Bank sebagai Peserta) atau direktur yang membawahi satuan kerja pengawasan intern (khusus bagi Pihak Selain Bank sebagai Peserta) kepada:

Direktorat Akunting dan Sistem Pembayaranc.q. Bagian Penyelenggaraan SetelmenBank Indonesia, Gedung D Lantai 3Jalan MH. Thamrin No. 2Jakarta 10350

g) Melakukan security audit sekurang-kurangnya 1 (satu) kali dalam jangka waktu 1 (satu) tahun sejak menjadi Peserta dan setiap terjadi perubahan dalam sistem teknologi informasi internal Peserta yang terkait dengan Sistem BI-RTGS.

Pelaksanaan security audit ini wajib dilakukan dengan mengacu pada dan tidak bertentangan dengan Surat Edaran ini, kesepakatan tertulis antar Peserta (Bye-Laws) dan mengacu pada cakupan minimum security audit yang ditetapkan oleh Penyelenggara. dan paling kurang mencakup ruang lingkup security audit sebagaimana diatur dalam Lampiran 3.7.

Khusus untuk Peserta Langsung yang menyediakan RT bagi Peserta Tidak Langsung, security audit tersebut mencakup pula security audit pada Peserta Tidak Langsung dengan ruang lingkup yang sama pada Lampiran 3.7.

h) Menyampaikan laporan hasil security audit sebagaimana dimaksud pada huruf g).

Laporan hasil security audit yang disampaikan berupa ringkasan hasil security audit yang dilakukan oleh Peserta, antara lain berupa temuan, tanggapan auditee dan rekomendasi hasil security audit. Laporan hasil security audit disampaikan dengan surat pengantar yang ditandatangani oleh Direktur Kepatuhan (khusus bagi Bank sebagai Peserta)

Langsung …

Direktorat …


atau direktur yang membawahi satuan kerja pengawasan intern (khusus bagi Pihak Selain Bank sebagai Peserta) kepada:

Direktorat Akunting dan Sistem Pembayaranc.q. Bagian Penyelenggaraan SetelmenBank Indonesia, Gedung D Lantai 3Jalan MH. Thamrin No. 2Jakarta 10350

i) Menyusun kebijakan teknologi informasi terkait dengan Sistem BI-RTGS yang di-review dan di-up date secara reguler.

j) Memiliki pedoman Disaster Recovery Plan (DRP) atau Business Continuity Plan (BCP) yang sekurang-kurangnya memuat langkah-langkah yang akan dilakukan dalam hal terjadi gangguan untuk memastikan bahwa operasional Sistem BI-RTGS di Peserta tetap dapat dilakukan atau upaya lainnya yang perlu dilakukan dalam hal sistem back-up tidak dapat digunakan.

Penyusunan pedoman DRP atau BCP ini wajib dilakukan dengan mengacu pada dan tidak bertentangan dengan PBI tentang Sistem BI-RTGS dan aturan pelaksanaannya serta kesepakatan tertulis antar Peserta (Bye-Laws).

Pedoman DRP atau BCP dimaksud sekurang-kurangnya memuat materi sebagai berikut:

(1) Unit kerja sebagai penanggungjawab;

(2) Mekanisme koordinasi apabila penanggungjawab terdiri dari beberapa unit;

(3) Mekanisme pelaporan dan monitoring; dan

(4) Petugas operasional (termasuk data nomor telepon yang dapat dihubungi setiap saat).

k) menyediakan dan menggunakan jaringan komunikasi data back-up dalam hal terdapat gangguan pada jaringan komunikasi data utama.

l) melakukan langkah-langkah preventif yang diperlukan sehingga perangkat keras (hardware) dan perangkat lunak aplikasi (system software) yang digunakan dalam Sistem BI-RTGS dan/atau dalam kaitannya dengan Sistem BI-RTGS bebas dari segala jenis virus.

m) menjamin keamanan dan kehandalan jaringan komunikasi data yang menghubungkan RT Server Utama dan/atau RT Server Back-up dengan RCC Utama dan/atau RCC Back-up, dalam hal Peserta menggunakan jaringan komunikasi data selain yang telah disediakan Penyelenggara sebagaimana


dimaksud pada butir a.1).

n) menjamin keamanan jaringan komunikasi data yang digunakan untuk menghubungkan RT Server Utama dan/atau RT Server Back-up dengan RT Workstation dan/atau RT Workstation back-up, sehingga bebas dari segala kemungkinan sumber perusak Sistem BI-RTGS termasuk tetapi tidak terbatas pada kemungkinan pemalsuan (fraud), pembobolan data elektronis (hacking), serta perusakan sistem dengan cara membanjiri sistem dengan data dan pesan pembayaran.

o) menjamin bahwa sistem komputerisasi Peserta aman dan bebas dari segala kemungkinan sumber perusak Sistem BI-RTGS termasuk tetapi tidak terbatas pada kemungkinan pemalsuan (fraud), pembobolan data elektronis (hacking), serta perusakan sistem dengan cara membanjiri sistem dengan data dan pesan pembayaran, dalam hal Peserta menghubungkan RT dengan sistem komputerisasi internal lainnya yang telah atau yang akan ada pada Peserta.

p) menyampaikan laporan mengenai lokasi RT Server Back-up, termasuk nama dan alamat penyelenggara RT Server Back-up dalam hal Peserta menggunakan jasa pihak lain, lengkap dengan konfigurasi RT Server Back-up dalam hubungannya dengan RT dan sistem-sistem komputerisasi lainnya yang ada pada Peserta serta metode pengamanan (security features) yang digunakan.

q) Pengurus dan atau pejabat eksekutif Bank Peserta sebagaimana dimaksud dalam ketentuan Bank Indonesia mengenai fit and proper test wajib melaksanakan langkah-langkah yang diperlukan untuk memastikan ketaatan Peserta terhadap ketentuan Bank Indonesia yang mengatur mengenai penyelenggaraan Sistem BI-RTGS, prinsip-prinsip penyelenggaraan dan pengawasan Sistem BI-RTGS, dan perlindungan kepada nasabah Peserta. Langkah-langkah yang perlu dilakukan antara lain melakukan monitoring atas penerapan security audit dan pemeriksaan internal.

12. Akses Informasi perihal Ketentuan dan Prosedur

Peserta dapat mengakses ketentuan dan prosedur yang dikeluarkan oleh Penyelenggara melalui:

b. Website Penyelenggara;

c. Compact Disc (CD); atau

d. Media lain yang disediakan oleh Penyelenggara.

B. Kondisi gangguan dan/atau Keadaan Darurat

1. Kondisi gangguan dan/atau Keadaan Darurat di Penyelenggara

RT …


a. Kondisi gangguan pada RCC Utama atau Keadaan Darurat di lokasi produksi Penyelenggara

1) Penyelenggara

a) Dalam hal terjadi gangguan pada RCC Utama sehingga Penyelenggara tidak dapat menggunakan RCC Utama, maka Penyelenggara menggunakan RCC Back-up.

b) Penyelenggara memberitahukan kepada seluruh Peserta apabila terjadi gangguan pada RCC Utama dan langkah-langkah yang perlu dilakukan melalui sistem Laporan Harian Bank Umum (LHBU) atau sarana lain.

2) Peserta

a) Menghentikan transaksi selama proses recovery dan Peserta tidak boleh mengirimkan transaksi sampai dengan adanya pemberitahuan lebih lanjut.

b) Setelah proses Recovery selesai, melakukan online retrieve untuk me-retrieve 5 (lima) transaksi terakhir “Retrieve Txn from RCC” yang dikirim RT dan cek status transaksi.

c) Melakukan “Member Own Total” untuk memeriksa posisi saldo.

d) Peserta harus menginformasikan kepada Penyelenggara apabila terdapat ISN IFTS Txn yang “hilang atau tidak lengkap”.

b. Kondisi gangguan pada jaringan komunikasi data Mekanisme USD/IDR PvP

Dalam hal terjadi gangguan pada jaringan komunikasi data USD/IDR PvP yang menyebabkan tidak dapat dilaksanakannya Mekanisme USD/IDR PvP, maka Penyelenggara menginformasikan kepada Peserta melalui administrative message untuk menyelesaikan Transaksi PvP diluar Mekanisme USD/IDR PvP.

c. Kondisi gangguan pada RCC Utama dan RCC Back-up

1) Dalam hal terjadi kondisi gangguan pada RCC Utama dan RCC Back-up maka Penyelenggara menerapkan BCP dan memberitahukan kondisi tersebut kepada Peserta berikut langkah-langkah yang perlu dilakukan melalui sistem LHBU atau sarana lainnya.

2) Langkah-langkah yang harus dilakukan antara lain Peserta menyampaikan kepada Bank Indonesia Cek BI dan/atau Bilyet Giro Bank Indonesia (BGBI) yang telah diberi cap Contingency Plan di belakang warkat tersebut.

d. Pengaruh terjadinya kondisi gangguan pada RCC Utama dan Keadaan Darurat pada lokasi produksi Penyelenggara terhadap kewajiban Peserta

1) Dalam hal RCC Utama tidak berfungsi sehingga menyebabkan

a) Dalam …

dengan …


Peserta tidak dapat melaksanakan transaksi melalui Sistem BI-RTGS, kewajiban Peserta yang terkait dengan pelaksanaan transaksi melalui Sistem BI-RTGS yang tidak dapat terlaksana karena tidak berfungsinya RCC ditunda pelaksanaannya sampai dengan berakhirnya kondisi tidak berfungsinya RCC.

Contoh: RCC tidak dapat berfungsi melebihi batas waktu transaksi untuk untung nasabah. Sehubungan dengan hal ini bagi Bank yang telah menerima instruksi transfer dari nasabah sebelum berakhirnya jam pelayanan nasabah untuk transfer melalui Sistem BI-RTGS di Bank yang bersangkutan melaksanakan instruksi transfer dari nasabah tersebut keesokan harinya.

2) Dalam hal terjadi kondisi sebagaimana dimaksud pada angka 1), Peserta harus melakukan langkah-langkah yang diperlukan yang terkait dengan penyelesaian kewajiban Peserta antara lain menyarankan kepada nasabah untuk menggunakan sarana kliring dengan memperhatikan ketentuan yang mengatur mengenai batasan nominal warkat atau data keuangan elektronik, sarana transfer lainnya atau diambil secara tunai.

e. Pengaruh terjadinya kondisi gangguan pada jaringan komunikasi yang menghubungkan RCC dengan USD CHATS

Dalam hal terjadi kondisi gangguan pada jaringan komunikasi yang menghubungkan RCC dengan infrastruktur teknologi informasi Mekanisme USD/IDR PvP sehingga Peserta tidak dapat melaksanakan Penyelesaian Akhir transaksi jual-beli USD/IDR melalui Mekanisme USD/IDR PvP, maka penyelesaian akhir atas transaksi jual beli USD/IDR tersebut dapat dilakukan antara lain dengan memperhatikan mekanisme sebagaimana dimaksud dalam kesepakatan antar Peserta yang tertuang dalam Bye Laws Mekanisme USD/IDR PvP.

2. Kondisi gangguan dan/atau Keadaan Darurat di Peserta

a. Kondisi gangguan pada RT Server Utama

Dalam hal terjadi gangguan terhadap RT Server Utama sehingga Peserta tidak dapat menggunakan RT Server Utama, maka Peserta harus menggunakan RT Server Back-up.

Penyelenggara dapat memberikan persetujuan kepada Peserta yang RT Server Utamanya mengalami kondisi gangguan untuk langsung menggunakan Fasilitas Guest Bank dalam melakukan transaksi Sistem BI-RTGS. Hal tersebut antara lain didasarkan pada pertimbangan bahwa waktu yang dibutuhkan untuk menghidupkan RT Server Back-up cukup lama sehingga Peserta tidak mempunyai cukup waktu untuk melakukan transaksi tertentu, seperti transaksi penarikan tunai, transaksi dengan pemerintah dan kewajiban antar Peserta yang telah jatuh tempo sesuai dengan Jam Operasional.

Apabila RT Server Back-up yang digunakan merupakan warm back-up


atau cold back-up maka Peserta harus melakukan restore back-up data ke sistem back-up dengan prosedur rekonsiliasi sebagai berikut:

1) me-restore data back-up terakhir melalui fungsi aplikasi RT super;

2) melakukan proses batch processing (end of day report, back-up, dan reset system);

3) menggunakan konfigurasi utility untuk melakukan setting BOR terakhir ke BOR yang belum dipakai dalam hari tersebut untuk mencegah adanya duplikasi BOR;

4) melakukan fungsi system start-up;

5) melakukan fungsi department start-up;

6) melakukan log-on ke RCC;

7) melakukan member enquiry-member own total;

8) melakukan cetak retrieve transaction dari RCC untuk 5 (lima) transaksi terakhir;

9) melakukan rekonsiliasi antara data 5 (lima) transaksi terakhir menurut catatan Peserta dengan retrieve transaksi dari RCC untuk 5 (lima) transaksi terakhir; dan

10) re-construct transaksi yang telah di-approve pada saat kegagalan terjadi dimana acknowledgement belum diterima oleh RCC.

b. Kondisi gangguan pada RT Server Utama dan RT Server Back-up atau Keadaan Darurat di lokasi Peserta

Dalam hal Peserta mengalami kondisi gangguan pada RT Server Utama dan RT Server Back-up atau mengalami Keadaan Darurat, Peserta dapat melakukan transaksi Sistem BI-RTGS dengan mekanisme sebagai berikut:

1) Menggunakan Fasilitas RT yang disediakan oleh Penyelenggara di lokasi Kantor Pusat Bank Indonesia (Fasilitas Guest Bank) dengan ketentuan sebagai berikut:

a) Syarat permohonan penggunaan Fasilitas Guest Bank

Peserta dapat mengajukan permohonan penggunaan Fasilitas Guest Bank dalam hal:

(1) RT Server Utama dan RT Server Back-up tidak berfungsi;

(2) RT Server Utama tidak berfungsi dan Peserta membutuhkan waktu cukup lama untuk menghidupkan RT Server Back-up sehingga Peserta tidak mempunyai cukup waktu untuk melakukan transaksi tertentu;

(3) jaringan komunikasi data antara RT Peserta dengan RCC tidak berfungsi; dan/atau

(4) terjadi Keadaan Darurat yang menyebabkan RT Server Utama dan RT Server Back-up tidak dapat digunakan.

dan …


b) Prosedur permohonan penggunaan Fasilitas Guest Bank

Peserta mengajukan permohonan penggunaan Fasilitas Guest Bank dengan prosedur sebagai berikut:

(1) Peserta mengajukan permohonan penggunaan Fasilitas Guest Bank kepada Penyelenggara melalui surat dengan didahului permintaan melalui telepon. Surat dimaksud disampaikan kepada Penyelenggara dan dapat disampaikan terlebih dahulu melalui faksimili sebelum penggunaan Fasilitas Guest Bank dengan memperhatikan kecukupan waktu untuk melakukan persiapan penggunaan Fasilitas Guest Bank dan window time transaksi. Contoh surat permohonan penggunaan Fasilitas Guest Bank adalah sebagaimana dimaksud pada Lampiran 3.8.a (untuk Peserta Sistem BI-RTGS) dan Lampiran 3.8.b (untuk Peserta Sistem BI-RTGS yang juga peserta BI-SSSS).

(2) Surat permohonan sebagaimana dimaksud pada angka (1) disampaikan kepada Penyelenggara dengan alamat:

Direktorat Akunting dan Sistem Pembayaranc.q. Bagian Penyelenggaraan SetelmenBank Indonesia, Gedung D Lantai 3Jl. M.H. Thamrin No.2Jakarta 10350

(3) Dalam hal Peserta juga merupakan peserta BI-SSSS maka surat permohonan tersebut juga ditembuskan kepada penyelenggara BI-SSSS.

(4) Peserta dapat menggunakan Fasilitas Guest Bank setelah asli surat permohonan sebagaimana dimaksud pada angka (1) diterima oleh Penyelenggara.

(5) Penyelenggara tidak bertanggung jawab atas segala kerugian yang timbul pada Peserta sehubungan dengan pelaksanaan transaksi melalui Fasilitas Guest Bank.

c) Penggunaan Fasilitas Guest Bank

Peserta Sistem BI-RTGS dapat menggunakan Fasilitas Guest Bank dengan ketentuan sebagai berikut:

(1) Fasilitas Guest Bank dapat digunakan selama Jam Operasional Sistem BI-RTGS.

(2) Transaksi yang dapat dilakukan melalui Fasilitas Guest Bank adalah seluruh transaksi Sistem BI-RTGS yang window time-nya masih terbuka pada saat penggunaan Fasilitas Guest Bank.

(3) Peserta harus membawa data back-up RT terakhir untuk di-restore pada Fasilitas Guest Bank dengan

Guest …


menggunakan media, antara lain CD atau flash disk.

(4) Peserta membawa data transaksi yang akan dibukukan melalui Fasilitas Guest Bank. Data transaksi tersebut dapat berupa warkat pembukuan atau data elektronik yang akan di up-load ke dalam aplikasi RT.

(5) Dalam hal jumlah Peserta yang mengajukan permohonan melebihi kapasitas Fasilitas Guest Bank yang disediakan, Penyelenggara dapat menetapkan batas maksimal waktu penggunaan Fasilitas Guest Bank.

(6) Dalam hal terjadi Keadaan Darurat, Penyelenggara dapat membebaskan biaya penggunaan Fasilitas Guest Bank.

Pedoman teknis penggunaan Fasilitas Guest Bank ádalah sebagaimana dimaksud pada Lampiran 3.9.

2) Dalam hal Fasilitas Guest Bank yang disediakan oleh Penyelenggara sebagaimana dimaksud pada angka 1) tidak berfungsi, belum tersedia atau Peserta tidak memiliki waktu yang cukup untuk mengajukan permohonan penggunaan Fasilitas Guest Bank, maka transaksi dilakukan dengan menggunakan Cek BI dan/atau BGBI sesuai mekanisme sebagai berikut:

a) Penyampaian surat permohonan untuk menggunakan Cek BI dan/atau BGBI:

(1) Peserta yang berkedudukan di wilayah kerja KPBI

Peserta mengajukan surat permohonan dengan menggunakan format sebagaimana dimaksud pada Lampiran 3.10 yang ditandatangani oleh Direksi/pejabat penerima kuasa dengan hak substitusi dari Direksi yang telah memiliki spesimen tanda tangan di Penyelenggara.

Surat permohonan tersebut disampaikan kepada Penyelenggara dengan alamat:

Direktorat Akunting dan Sistem Pembayaranc.q. Bagian Penyelenggaraan SetelmenBank Indonesia, Gedung D Lantai 3Jl. M.H. Thamrin No.2Jakarta 10350

(2) Peserta yang berkedudukan di luar wilayah kerja KPBI

Peserta mengajukan surat permohonan kepada KBI setempat dengan menggunakan format sebagaimana dimaksud pada Lampiran 3.10 yang ditandatangani oleh Direksi/pejabat penerima kuasa dengan hak substitusi dari Direksi yang telah memiliki spesimen

yang …


tanda tangan di KBI setempat.

Surat permohonan tersebut antara lain memuat:

(1) alasan yang menyebabkan dilakukannya penggunaan Cek BI dan/atau BGBI;

(2) pernyataan bahwa yang bersangkutan membebaskan Bank Indonesia dari tanggung jawab (indemnity) atas keterlambatan pelaksanaan transfer dan segala kerugian yang timbul sehubungan dengan pelaksanaan construct oleh Bank Indonesia; dan

(3) jumlah dan nilai nominal Cek BI dan/atau BGBI yang akan diserahkan serta lokasi cabang Peserta yang akan melakukan transaksi menggunakan Cek BI dan/atau BGBI.

b) Apabila permohonan disetujui, Peserta menyampaikan Cek BI dan/atau BGBI yang diberi stempel Contingency Plan sebagaimana dimaksud pada Lampiran 3.11 di belakang Cek BI atau BGBI. Khusus untuk kantor cabang Peserta, penyerahan Cek BI dan/atau BGBI tersebut dilampiri dengan surat permohonan penggunaan Cek BI dan/atau BGBI kepada kantor Bank Indonesia setempat. Cek BI dan/atau BGBI diterima oleh kantor Bank Indonesia paling lambat sampai dengan jam tutup TRN transaksi yang bersangkutan.

c) Penyelesaian transaksi dengan menggunakan Cek BI dan/ atau BGBI dibatasi hanya untuk transaksi antar Peserta bukan untuk untung nasabah, kecuali transaksi yang ditujukan untuk nasabah Bank Indonesia.

d) Cek BI dan/atau BGBI tersebut dibukukan oleh Bank Indonesia melalui RT kantor Bank Indonesia.

e) Pembukuan transaksi oleh Bank Indonesia tetap mengacu pada Jam Operasional Sistem BI-RTGS yang berlaku sebagaimana dimaksud pada Lampiran 3.3.

f) Bukti pembukuan transaksi akan terkirim ke RT Peserta apabila RT Peserta telah berjalan normal. Khusus untuk transaksi setoran pajak maka bukti pelimpahan yang diserahkan kepada Kas Negara adalah re-print completion advice yang dibubuhi stempel tanda tangan pejabat Bank Indonesia.

g) Atas transaksi yang dibukukan tersebut, Penyelenggara akan membebankan biaya transaksi sesuai dengan tarif yang berlaku dan akan dibebankan secara langsung ke Rekening Giro Peserta paling lambat pada hari kerja berikutnya.

Sehubungan dengan kondisi di atas yang menyebabkan Peserta tidak dapat melaksanakan Penyelesaian Akhir transaksi jual beli

(2) pernyataan …

Bye-Laws …


USD/IDR melalui Mekanisme USD/IDR PvP, maka penyelesaian akhir atas transaksi jual beli USD/IDR tersebut dapat dilakukan antara lain dengan memperhatikan mekanisme sebagaimana dimaksud dalam kesepakatan antar Peserta yang tertuang dalam Bye-Laws Mekanisme USD/IDR PvP.

c. Kondisi gangguan pada jaringan komunikasi data dari RT Peserta ke RCC

1) Kondisi gangguan pada jaringan komunikasi data utama dari RT ke RCC

Dalam hal terjadi kondisi gangguan pada jaringan komunikasi data utama dari RT ke RCC maka Peserta menggunakan jaringan komunikasi data back-up, apabila telah tersedia, jaringan komunikasi data dengan Sentral Telepon Otomat (STO) yang berbeda.

2) Kondisi gangguan pada jaringan komunikasi data utama dan jaringan komunikasi data back-up dari RT ke RCC

Dalam hal jaringan komunikasi data utama dan jaringan komunikasi data back-up dari RT ke RCC mengalami kondisi gangguan, Peserta dapat melakukan transaksi Sistem BI-RTGS dengan mekanisme sebagai berikut:

a) Menggunakan fasilitas RT yang disediakan oleh Penyelenggara di lokasi Kantor Pusat Bank Indonesia (Fasilitas Guest Bank) sesuai dengan mekanisme sebagaimana dimaksud pada butir b.1).

b) Dalam hal Fasilitas Guest Bank yang disediakan oleh Penyelenggara sebagaimana dimaksud pada huruf a) tidak berfungsi, belum tersedia atau Peserta tidak memiliki waktu yang cukup untuk mengajukan permohonan penggunaan Fasilitas Guest Bank, maka transaksi dilakukan dengan menggunakan Cek BI dan/atau BGBI sesuai mekanisme sebagaimana dimaksud pada butir b.2).

C. Penggunaan BGBI dalam kondisi tertentu

Selain dalam kondisi gangguan dan/atau Keadaan Darurat sebagaimana dimaksud pada huruf B, khusus untuk transaksi-transaksi tertentu, antara Peserta dengan Pemerintah yang telah mendapat persetujuan Bank Indonesia, Peserta dapat menggunakan BGBI untuk dibukukan oleh Penyelenggara melalui Sistem BI-RTGS. Persetujuan Bank Indonesia tersebut diberikan sepanjang transaksi antara Peserta dengan Pemerintah dimaksud terkait dengan tugas Bank Indonesia di bidang moneter, perbankan dan sistem pembayaran.

BAB …BAB …

BAB …

Bab III Ketentuan Dan Prosedur Final

Documents

Transcript of Bab III Ketentuan Dan Prosedur Final