Skripsi - Bethari Zattira 1112091000128

RANCANGAN APLIKASI INTERFACE DAN INTEGRASI BI-
RTGS GEN II DENGAN SISTEM BANK PESERTA BI-RTGS
(Studi Kasus : PT. Visigo)
SKRIPSI
Sebagai Salah Satu Syarat Untuk Meraih Gelar Sarjana Komputer
Disusun Oleh:
Bethari Zattira
NIM. 1112091000128
PROGRAM STUDI TEKNOLOGI INFORMASI
FAKULTAS SAINS DAN TEKNOLOGI
UNIVERSITAS ISLAM NEGERI SYARIF HIDAYATULLAH
JAKARTA
1440 H/2019 M
i
UIN SYARIF HIDAYATULLAH JAKARTA

ii

PERNYATAAN ORISINALITAS
Dengan ini saya menyatakan bahwa:
1. Skripsi ini benar-benar hasil karya Saya sendiri diajukan untuk memenuhi
salah satu persyaratan memperoleh gelar Strata 1 di UIN Syarif Hidayatullah
Jakarta.
2. Sumber yang Saya gunakan dalam penulisan ini telah Saya cantumkan sesuai
dengan ketentuan yang berlaku di UIN Syarif Hidayatullah Jakarta.
Jakarta, Mei 2019
Bethari Zattira
NIM. 1112091000128
iii

KATA PENGANTAR
Puji dan syukur penulis panjatkan kehadirat Allah SWT atas segala rahmat
dan karunia-Nya yang telah diberikan kepada penulis sehingga penulis dapat
menyelesaikan penelitian dan penulisan skripsi ini. Shalawat dan Salam selalu
tersampaikan kepada Nabi Besar Muhammad SAW, keluarga, sahabat dan para
pengikutnya hingga akhir zaman.
Skripsi penulis yang berjudul “Rancangan Aplikasi Interface dan
Integrasi BI-RTGS Dengan Sistem Bank Peserta BI-RTGS ” disusun untuk
memenuhi salah satu syarat dalam menyelesaikan Program Strata Satu (S1) pada
Program Studi Teknik Informatika, Universitas Islam Negeri Syarif Hidayatullah
Jakarta.
Suatu kebanggan tersendiri bagi penulis apabila skripsi ini dapat
bermanfaat terutama bagi pihak-pihak yang membutuhkannya. Pada kesempatan
ini, penulis ingin mengucapkan terima kasih kepada pihak-pihak yang telah
membantu penulis, baik secara moril maupun materil, sehingga penulisan ini
terlaksana dengan baik. Secara khusus penulis mengucapkan terimakasih kepada:
1. Ibu Prof.Dr.Lily Surraya Eka Putri,M.Env.Stud, Selaku Dekan Fakultas Sains
dan Teknologi.
2. Ibu Arini, MT selaku Ketua Program Studi Teknik Informatika dan Bapak
Feri Fahrianto, Sc selaku Sekretaris Jurusan Program Studi Teknik
Informatika, yang selalu memberikan motivasi dan arahan kepada penulis.
iv

3. Ibu Arini, MT selaku Dosen Pembimbing I dan Bapak Victor Amrizal,
M.Kom selaku Dosen Pembimbing II, yang telah memberikan arahan atau
bimbingan kepada penulis.
4. Seluruh Dosen Program Studi Teknik Informatika, Fakultas Sains dan
Teknologi. Yang telah banyak memberikan bimbingan dan pengarahan
kepada penulis selama menjalankan aktifitas perkuliahan.
5. Taufik Indra P, selaku suami tampan tiada tara yang telah memberikan
support tak terbatas dan memperjuangkan apapun agar peneliti dapat
menyelesaikan penelitian skripsi ini.
6. Ayahanda dan Ibunda tercinta Bapak Armen dan Ibu Marhaerita, atas
dukungan dan doa yang tidak pernah berhenti.
7. Odang dan Pak Odang, yang tidak pernah absen bertanya kapan skripsi
penulis selesai.
8. Dan kepada seluruh keluarga penulis yang tidak bisa disebutkan satu persatu
9. Terimakasih juga buat teman spesial saya Eldest Nediasa dan Lidya Novianti
F, Fikha Pratikta, Faizal Bachri, Brenda Marsalia dan seluruh sahabat terdekat
saya lainnya yang telah memberikan motivasi agar penulis menyelesaikan
studi S1 sesegera mungkin.
10. Terimakasih juga untuk teman sekelas semasa mengulang 48 sks lebih Hana
Faiqah, Aisyah, Devi, Ani Ramadhani, dan seluruh teman yang terlalu banyak
untuk disebutkan satu per satu.
11. Terimakasih kepada rekan-rekan seperjuangan di UIN Syarif Hidayatullah
Jakarta, yang telah memberikan dukungan dan semangat serta saran-saran
yang berguna hingga akhir penulisan skripsi ini.

12. Semua pihak yang telah membantu penulis dalam menyelesaikan skripsi ini,
yang tidak dapat penulis sebutkan satu per satu. Semoga Allah SWT
memberikan berkah dan karunia-Nya serta membalas kebaikan mereka.
Amin.
vi

Nama : Bethari Zattira
Program Studi : Teknik Informatika
Judul : Rancangan Aplikasi Interface dan Integrasi BI-RTGS
Gen II Dengan Sistem Bank Peserta BI-RTGS
ABSTRAK
Untuk meningkatkan keamanan lalu lintas transaksi penyaluran dana, Bank

Indonesia selaku bank sentral yang menaungi seluruh bank yang beroperasi di
Indonesia sudah menerbitkan sebuah sistem sentralisasi lalu lintas transaksi yang
bernama Real Time Gross Settlement (BI-RTGS). Sebagai sebuah sistem besar
yang menaungi jalannya transaksi penyaluran dana bernilai besar (High Value
Payment System) sistem BI-RTGS ini mengadakan perubahan guna
meningkatkan perlindungan pada setiap lalu lintas transaksi keuangan yang ada.
Perubahan tersebut salah satunya adalah perubahan metode format messaging
berskala internasional yang dinamakan Swift. Oleh karena itu, setiap bank peserta
yang menggunakan layanan BI-RTGS ini diwajibkan untuk melakukan
perubahan, agar format baru ini dapat diintegrasikan dengan sistem bank peserta
tersebut. Namun bagi beberapa bank, channel transaksi BI-RTGS sudah
terintegrasi langsung dengan core banking. Dimana jika terdapat perubahan pada
core banking akan beresiko mengganggu channel transaksi lain. Oleh karena itu
dibutuhkan sebuah aplikasi perantara yang digunakan untuk menghubungkan
channel RTGS pada core banking dengan format baru BI-RTGS. Aplikasi
tersebut akan melakukan konversi antara format messaging lama dengan format
Swift yang ada pada sistem BI-RTGS.
Kata Kunci : Format Messaging, Swift Code, PHP, Node.js
vii

DAFTAR ISI
LEMBAR PESETUJUAN PEMBIMBING ....................................................i

LEMBAR PENGESAHAN ..............................................................................ii
PERNYATAAN ORISINALITAS...................................................................iii
KATA PENGANTAR .......................................................................................iv
ABSTRAK .........................................................................................................vi
DAFTAR ISI ......................................................................................................vii
DAFTAR GAMBAR .........................................................................................x
DAFTAR TABEL .............................................................................................xi
DAFTAR LAMPIRAN .....................................................................................xii
DAFTAR SIMBOL ...........................................................................................xiii
BAB I PENDAHULUAN
1.1. Latar Belakang .................................................................................1
1.2. Identifikasi Masalah .........................................................................5
1.3. Rumusan Masalah ............................................................................6
1.4. Batasan Masalah ...............................................................................7
1.5. Tujuan Penelitian..............................................................................7
1.6. Manfaat Penelitian............................................................................8
1.7. Metode Penelitian.............................................................................8
1.8. Sistematika Penulisan.......................................................................9
BAB II LANDASAN TEORI
2.1. Definisi Pengembangan...................................................................11

2.2. Definisi Aplikasi ..............................................................................11
2.3. Core Banking....................................................................................12
2.4. BI RTGS ...........................................................................................12
2.5. Swift ................................................................................................15
2.6. Swift Code ........................................................................................17
2.7. Metode Pengembangan Sistem ........................................................18
2.8. Metode Pengumpulan Data ..............................................................21
2.9. UML (Unified Modeling Language) ................................................24
viii

2.10. Bahasa Pemograman dan Basis Data .............................................29
2.11. Framework .....................................................................................29
BAB III METODOLOGI PENELITIAN
3.1 Metode Pengumpulan Data ..............................................................34
3.2 Metode Pengembangan Sistem ........................................................36
3.3 Tahap Perencanaan Syarat-Syarat ....................................................37
3.4 Tahap Workshop Desain RAD .........................................................38
3.5 Tahap Implementasi .........................................................................39
3.6 Kerangka Penelitian .........................................................................40
BAB IV ANALISIS, PERANGANCAN, DAN IMPLEMENTASI
4.1. Pengumpulan Data ...........................................................................41
4.1.1. Observasi ................................................................................41
4.1.2. Wawancara .............................................................................41
4.1.3. Studi Pustaka ..........................................................................42
4.2. Tahap Perencanaan Syarat-Syarat ....................................................43
4.2.1. Identifikasi Masalah................................................................43
4.2.2. Analisa Sistem ........................................................................44
4.2.3. Analisa Sistem Berjalan ..........................................................45
4.2.4. Sistem Usulan .........................................................................46
4.3. Tahap Workshop Design ..................................................................47
4.3.1. Outgoing File Core banking ..................................................48
4.3.2. Incoming File Core banking ...................................................52
4.3.3. Pengenalan MT BI-RTGS GEN II .........................................60
4.3.4. Desain UML ...........................................................................63
4.3.5. Desain Database......................................................................78
4.3.6. Desain Antarmuka ..................................................................79
4.4. Tahap Implementasi .........................................................................89
4.4.1. Perangkat Yang Digunakan ...................................................89
4.4.2. Pembuatan Sistem ...................................................................91
4.4.3. Instalasi Sistem .......................................................................93
4.4.4. Pengoperasian Sistem .............................................................94
ix

4.4.5. Pengujian Sistem ....................................................................94
BAB V HASIL DAN PEMBAHASAN
5.1 Komunikasi dan Cara Messaging .....................................................98

5.1.1. Koneksi dari Interface dengan BI-RTGS server (RTSX). ......98
5.1.2. Koneksi dari Core Banking dengan Interface. ........................100
5.2. Flow Transaksi ................................................................................101
5.2.1. Flow Outgoing ........................................................................101
5.2.2. Flow Incoming ........................................................................102
5.2.3. Pembahasan Sistem ................................................................103
BAB VI PENUTUP
6.1. Kesimpulan.......................................................................................109
6.2. Saran ..............................................................................................109
DAFTAR PUSTAKA ........................................................................................111

DAFTAR GAMBAR
Gambar 2.1. Alur pembayaran lintas negara..................................................16

Gambar 2.2 Skema RAD (Kendall 2010) .....................................................20
Gambar 2.3 Contoh Use Case Diagram .......................................................25
Gambar 2.4 Contoh Activity Diagram ..........................................................26
Gambar 2.5 Keterangan Activity Diagram....................................................27
Gambar 2.6 Contoh Sequence Diagram .......................................................27
Gambar 2.7 Application Flowchart ...............................................................30
Gambar 2.8 Model-View-Controller.............................................................32
Gambar 3.1 Kerangka Berpikir .....................................................................40
Gambar 4.1 Skema Sistem Berjalan .............................................................45
Gambar 4.2 Skema Sistem Usulan................................................................46
Gambar 4.3. Format MT900 untuk BI-RTGS ...............................................62
Gambar 4.4 Use Case Monitoring Incoming ................................................68
Gambar 4.5 Use Case Monitoring Outgoing ................................................68
Gambar 4.6 Use Case Dashboard .................................................................69
Gambar 4.7 Contoh file MT103 untuk BI-RTGS .........................................71
Gambar 4.8 Use Case Setting .......................................................................72
Gambar 4.9 Activity Diagram transaksi incoming .......................................73
Gambar 4.10 Alur Activity diagram untuk transaksi Outgoing ......................74
Gambar 4.11 Alur sequence diagram untuk transaksi incoming positif .........75
Gambar 4.12 Alur sequence diagram untuk transaksi hold incoming ............76
Gambar 4.13 Alur sequence diagram untuk transaksi incoming positif .........78
Gambar 4.14 Alur sequence diagram untuk transaksi hold outgoing .............79
Gambar 4.15 Database Diagram .....................................................................79
Gambar 4.16 Halaman Awal Sistem ...............................................................79
Gambar 4.17 Halaman Home monitoring .......................................................79
Gambar 4.18 Halaman Home dashboard ........................................................81
Gambar 4.19 Halaman Home monitoring .......................................................82
Gambar 4.20 Halaman User Maintenance ......................................................83
xi

Gambar 4.21 Halaman Member Maintenance ................................................84
Gambar 4.22 Halaman System Configuration ................................................85
Gambar 4.23 Halaman Account Blacklist.......................................................85
Gambar 4.24 Halaman amount capping..........................................................86
Gambar 4.25 Halaman File & Folders – Folders ............................................87
Gambar 4.26 Halaman File & Folders – FTP .................................................87
Gambar 4.27 Halaman Report ........................................................................88
Gambar 4.28 Halaman Pencarian Transaksi ...................................................89
Gambar 5.1 Flow Outgoing ..........................................................................101
Gambar 5.2 Flow Incoming ..........................................................................102
Gambar 5.3 Format Fixed Length Core Banking .........................................103
Gambar 5.4. Format Swift BI-RTGS .............................................................104
Gambar 5.5 Halaman Utama pada operator ..................................................104
Gambar 5.6 Transaksi Masuk pada Menu Operator .....................................105
Gambar 5.7 Detail Transaction Core Banking ..............................................106
Gambar 5.8 Detail Transaction Swift Messaging .........................................107
Gambar 5.9 Permintaan Request Oleh Operator ...........................................107
Gambar 5.10 Waiting Approval pada User Operator .....................................108
Gambar 5.11 Waiting approval supervisor .....................................................108
Gambar 5.12 Disaprove dan Approve Supervisor ..........................................108
xii

DAFTAR TABEL
Tabel 2.1 Klasifikasi Message Type .........................................................18

Tabel 3.1 Studi Literatur Sejenis ...............................................................35
Tabel 4.1 Outgoing messaging spesification bank peserta .......................48
Tabel 4.2 Studi Literatur Sejenis ...............................................................48
Tabel 4.3 Inquiry Messaging Specification...............................................53
Tabel 4.4 Pengujian Blackbox ..................................................................94
Tabel 4.5 Respond Inquiry RTGS File .....................................................54
Tabel 4.6 Incoming RTGS File .................................................................59
Tabel 4.7 Respon Status Posting Incoming RTGS ...................................60
Tabel 4.8 Format MT103 untuk BI-RTGS ...............................................61
Tabel 4.9 Format MT900 untuk BI-RTGS ...............................................63
Tabel 4.10 Identifikasi Aktor ......................................................................67
Tabel 4.11 Identifikasi Use Case Monitoring Incoming .............................69
Tabel 4.12 Identifikasi Use Case Monitoring Outgoing .............................71
Tabel 4.13 Identifikasi Use Case Dashboard ..............................................69
Tabel 4.14 Identifikasi Use Case Setting ....................................................71
xiii

DAFTAR LAMPIRAN
xiv

BAB I
PENDAHULUAN
1.1. Latar Belakang

Perkembangan regulasi perbankan di Indonesia saat ini berkembang
pesat dari waktu ke waktu. Perubahan tatanan regulasi perbankan ini antara
lain dipengaruhi oleh perkembangan jasa keuangan dan perbankan global
serta munculnya beragam produk perbankan dan layanan jasa perbankan
yang diperbarui. Terlebih lagi dengan banyaknya kebutuhan masyarakat
khususnya pelaku bisnis yang membutuhkan layanan penyaluran dana
dengan nominal besar dalam waktu yang super singkat. Oleh karena itu,
Untuk meningkatkan mitigasi resiko yang terjadi pada lalu lintas
transaksi dalam penyaluran dana, maka Bank Indonesia sebagai bank sentral
yang menaungi semua bank yang beroperasi di indonesia menerbitkan
sistem sentralisasi lalu lintas transaksi yang dinamakan BI-RTGS (Real
Time Gross Settlement) untuk memonitoring dan memfasilitasi semua
transaksi dalam jumlah besar dan dengan waktu yang singkat. BI-RTGS
yang kehadirannya di Indonesia dimulai sejak tanggal 17 November 2000
ini dinilai sangat penting mengingat sebelumnya transaksi pembayaran
bernilai besar (High Value Payment System) memiliki potensi terjadinya
risiko sistemik yang menempati bagian mayoritas dari seluruh transaksi
pembayaran. Sistem BI-RTGS merupakan proses penyelesaian akhir
transaksi (settlement) pembayaran yang dilakukan per transaksi
(individually processed / gross settlement) dan bersifat real time

2
(electronically processed), dimana rekening peserta dapat didebit/dikredit
berkali-kali dalam sehari sesuai dengan perintah pembayaran dan
penerimaan pembayaran. Sebelumnya sistem BI-RTGS yang sudah berjalan
selama 1 dekade untuk menunjang transaksi dengan nominal besar ini hanya
mampu membuat prioritas dalam bentuk FIFO (first in first out) dan dinilai
kurang baik dalam manajemen prioritas dan hanya menunjang transaksi
dalam bentuk nilai tukar rupiah.
Oleh karena itu, Bank Indonesia selaku bank sentral mengeluarkan
surat pemberitahuan bahwa akan ada pembaruan teknologi untuk
meningkatkan perlindungan pada nasabah. Maka bank peserta yang terdaftar
pada sistem BI yang terdaftar pada layanan BI-RTGS diharuskan untuk
melakukan penyesuain integrasi sistem yang akan diterapkan oleh BI di
pembaruan yang akan ditetapkan ini. Pembaruan sistem ini diberi nama
dengan sistem generasi II serta sudah di implementasikan pada tanggal 16
november 2016 pada berita pers website resmi Bank Indonesia, serta
informasi ini diterbitkan pada tanggal 11 november 2016 dan informasi
mengenai rencana pembaruan ini sudah ada sejak enam tahun sebelum
implementasi ini dilaksanakan.
Pada beberapa bank yang terdaftar di layanan BI-RTGS ini telah
melakukan integrasi pada sistem core banking bank tersebut dan telah
menggunakan format teknologi yang diimplementasikan pada sistem BI-
RTGS sebelumnya. Dan jika terdapat pembaruan pada sistem BI-RTGS ini,
maka sudah pasti sistem pada core banking bank tersebut perlu dilakukan

3
perubahan pula. Sedangkan sistem pada core banking biasanya sudah
terintegrasi antara satu layanan dengan layanan lainnya sehingga
memerlukan biaya dan waktu yang besar untuk melakukan perubahan pada
sistem. Oleh karena itu dibutuhkan sebuah cara, berupa perancangan
interface sebagai middleware antara sistem baru BI-RTGS dengan sistem
core banking bank tersebut. Dengan perancangan aplikasi interface dan
integrasi RTGS dengan core banking ini diharapkan dapat mengakomodir
perubahan dari sistem BI-RTGS dengan biaya yang minimum dan
meminimalkan risiko gangguan sistem pada core banking yang telah
berjalan dengan baik.
Dalam perancangan pembuatan aplikasi interface dan integrasi BI-
RTGS ini, dibutuhkan pengetahuan mengenai format messaging BI-RTGS
pada sistem lama dan baru. Format messaging system merupakan standar
komunikasi antara pihak BI-RTGS dengan core banking. Sebelumnya
format messaging pada sistem BI-RTGS menggunakan format fixed length
dimana semua messaging memiliki panjang karakter yang tetap dan dipecah
berdasarkan urutan karakter. Hal ini semakin lama menjadi sebuah kesulitan
karena apabila terjadi penambahan dan pengurangan karakter akan
mengurangi susunan data. Oleh karena itu dibutuhkan standar messaging
dengan format baru agar kesulitan ini dapat diatasi. Oleh karena itu, pada
pengembangan sistem BI-RTGS, Bank Indonesia merubah format fixed
length menjadi format swift code messaging agar pemetaan struktur data
lebih mudah.

4
Dari hasil wawancara salah seorang IT engineer pada bank peserta
BI-RTGS, mengatakan bahwa transaksi BI-RTGS telah di implementasi di
beberapa channel transaksi seperti ATM, Internet banking ,Teller
Application dan lain-lain. Jika semua channel harus diubah formatnya akan
memakan waktu dan resource yang besar. IT engineer ini menyatakan ada
beberapa perubahan yang besar dari format lama ke format baru yaitu
konsep kode transaksi yang dahulu menggunakan format TRN (buku
pedoman umum BI-RTGS 17 november 2000) menjadi format MT yang
biasa digunakan di swift code messaging. di semua channel masih
menggunakan format TRN jelas ini tidak bisa lagi digunakan untuk
bertransaksi RTGS.
Berdasarkan hasil wawancara yang telah peneliti lakukan terdapat
beberapa masalah yang membuat peserta BI-RTGS kesulitan melakukan
penyesuaian :
a. Format kode yaitu TRN sudah di implementasi di berbagai channel
transaksi yang ada di bank maka dibutuhkan sebuah aplikasi yang dapat
memetakan kode transaksi TRN ke MT
b. Bahwa cara dan format messaging lama sudah berbeda dengan yang
baru yang sudah menggunakan format swift code messaging aplikasi
interface harus bisa merubah format lama yang ada di sistem bank
menjadi format swift.
Adapun studi literatur yang berkaitan dengan perancangan aplikasi
interface dan integrasi BI-RTGS gen II ini diantaranya :

5
1. Skripsi Salsabila (2018) Mekanisme Transaksi Real Time Gross
Settlement (RTGS) pada PT. Bank Tabungan Negara (Persero) Kantor
Cabang Pembantu Syariah Yogyakarta.
2. Ruth Wandhofer (2018) The Future of Correspondent Banking Cross
Border Payments.
3. Adam Fugal (2018) A Proposal For A Decentralized Liquidity Savings
Mechanism With Side Payments.
Dari beberapa studi literatur yang digunakan dan melihat dari latar
belakang pada bab ini, maka penulis akan mengadakan penelitian dengan
judul : Rancangan Aplikasi Interface dan Integrasi BI-RTGS GEN II
Dengan Sistem Bank Peserta BI-RTGS. Rancangan aplikasi ini dapat
digunakan oleh bank peserta BI-RTGS dalam pengembangan sistem
integrasi BI-RTGS yang lebih mudah diterapkan, meminimalkan cost dan
tidak perlu merubah keseluruhan dari sistem core-banking pada bank
peserta BI-RTGS tersebut.
1.2. Identifikasi Masalah

Berdasarkan uraian yang telah dijelaskan maka identifikasi masalah
yang dapat dijabarkan adalah sebagai berikut :
1. Saat ini sudah ada pembaruan pada sistem BI-RTGS menjadi Gen II
yang membuat para peserta lembaga keuangan di indonesia harus
merubah format messaging mereka ke format Gen II agar bisa
terintegrasi dengan BI-RTGS GEN II.

6
2. Beberapa lembaga keuangan masih menggunakan core banking yang
mengadopsi sistem format Gen I.
3. Membutuhkan cost yang mahal apabila harus merombak seluruh core
banking dan merubahnya menjadi format Gen II.
4. Jika perombakan tetap dilakukan maka akan ada perubahan yang bisa
mengganggu sistem yang sudah berjalan sebelumnya.
5. Pihak lembaga keuangan menginginkan core banking mereka tetap di
format Gen I akan tetapi ada aplikasi lain yang mengubah format
mereka ke Gen II.
1.3. Rumusan Masalah

Berdasarkan latar belakang diatas maka dapat ditarik rumusan
masalah tersebut terdiri dari :
1. Bagaimana merancang sistem interface yang dapat melakukan
koneksi antara sistem BI-RTGS dengan core banking bank peserta.
2. Bagaimana merancang aplikasi interface yang dapat menyesuaikan
kebutuhan core banking bank peserta tanpa harus melakukan
perubahan dari sistem core banking yang telah tersedia.
3. Bagaimana merancang sistem yang dapat melakukan konversi file
untuk menerjemahkan format yang baru pada sistem BI-RTGS
agar dapat dibaca oleh sistem core banking.

7
1.4. Batasan Masalah
Berdasarkan rumusan masalah yang telah diuraikan diatas, maka
batasan masalah pada penelitian skripsi ini adalah membahas mengenai:
1. Penelitian ini hanya membahas mengenai cara merancang aplikasi
interface yang menjadi jembatan antara BI-RTGS GEN II dengan core
banking (messaging GEN I)
2. Aplikasi interface yang dapat mensupport messaging format BI-RTGS
Gen II.
3. Aplikasi interface mensupport messaging format BI-RTGS Gen I yang
masih di gunakan oleh core banking.
4. Aplikasi interface mengakomodir fitur-fitur standar yang ada di core
banking jika format BI-RTGS GEN II tidak bisa di pakai di core
banking.
1.5. Tujuan Penelitian
Tujuan dari penelitian dalam penelitian skripsi ini adalah :
1. Merancang aplikasi converter dari format messaging lama (GEN I) ke

format messaging baru (BI-RTGS GEN II).
2. merancang aplikasi interface yang dapat menyesuaikan kebutuhan core

banking mereka tanpa harus ada perubahan dari sisi core banking.
3. Merancang aplikasi interface yang bisa memenuhi kebutuhan BI-RTGS

GEN II.

8
1.6. Manfaat Penelitian
Berikut ini adalah beberapa manfaat yang didapatkan dari penelitian
ini, yaitu:
1. Menjadi salah satu referensi jika terdapat pembaruan sistem kembali
dari BI atau lembaga lain.
2. Membatu perbankan/peserta BI-RTGS agar lebih mudah melakukan
implementasi perubahan yang ada di pembaruan BI-RTGS GEN II.
1.7. Metode Penelitian
Metode penelitian yang digunakan terdiri dari dua macam, yaitu
metode pengumpulan data dan metode pengembangan sistem.
1. Metode Pengumpulan Data
● Studi Pustaka
Mempelajari panduan mengenai sentralisasi perbankan negara, teori
mengenai sistem RTGS dan penggunaannya di Indonesia, dan
penggunaan format Swift.
● Observasi
Pengamatan langsung atau observasi merupakan teknik
pengumpulan data dengan langsung melihat kegiatan yang dilakukan
oleh user.
● Wawancara

9
Melakukan wawancara dengan salah seorang karyawan vendor yang
sedang mengerjakan proyek pengadaan aplikasi interface dan
integrasi BI-RTGS.
2. Metode Pengembangan Sistem
Metode pengembangan sistem yang digunakan menggunakan
metode Rapid Application Development (RAD). Metode ini terdiri dari
pemodelan bisnis, data, proses, pembuatan aplikasi, pengujian, dan
pergantian. Pada tahap pembuatan aplikasi, tools yang digunakan ialah
(Unified Modelling Language) UML. Diagram yang digunakan adalah
use case diagram, class diagram, sequence diagram, dan activity
diagram.
1.8. Sistematika Penulisan
Dalam penyusunan laporan skripsi ini disusun dengan sistematika
penulisan sebagai berikut :
BAB I PENDAHULUAN
Bab ini membahas secara keseluruhan mengenai penelitian
laporan.Bab ini berisi latar belakang, rumusan masalah, ruang lingkup,
tujuan, manfaat, metodologi penelitian, dan sistematika penulisan.
BAB II LANDASAN TEORI
Bab ini berisikan berbagai teori yang mendasari penelitian
permasalahan dan berhubungan dengan topik yang akan dibahas.

10
BAB III METODOLOGI PENELITIAN
Bab ini berisi uraian lebih rinci tentang metodologi penelitian yang
meliputi metodologi pengumpulan data dan metodologi pengembangan
sistem.
BAB IV PERANCANGAN DAN PEMBAHASAN
Bab ini berisi tentang perancangan sistem yang sedang berjalan dan
yang diusulkan.
BAB V PENUTUP
Bab ini berisi kesimpulan yang didapat dari hasil penelitian yang
dilakukan dan saran-saran yang dapat digunakan sebagai bahan masukan
untuk pengembangan lebih lanjut.

BAB II
LANDASAN TEORI
2.1. Definisi Pengembangan
Pengembangan adalah suatu usaha untuk meningkatkan kemampuan
teknis, teoritis dan konseptual sesuai dengan kebutuhan melalui pendidikan
dan latihan demi tercapainya suatu tujuan yang diinginkan (Wikipedia :
Kamus Besar Bahasa Indonesia).
2.2. Definisi Aplikasi
Menurut Jogiyanto (1999:12), Aplikasi merupakan penggunaan dalam
suatu komputer, intruksi (intruction) atau pernyataan (statement) yang
disusun sedemikian rupa sehingga komputer dapat memproses input
menjadi output. Menurut Kamus Besar Bahasa Indonesia (1998: 52),
Aplikasi adalah penerapan dari rancang sistem untuk mengolah data yang
menggunakan aturan atau ketentuan dari bahasa pemograman tertentu.
Aplikasi adalah suatu program komputer yang dibuat untuk
mengerjakan dan melaksanakan tugas khusus dari pengguna. Aplikasi
merupakan rangkaian kegiatan atau perintah untuk dieksekusi oleh
komputer.
Program merupakan kumpulan intruction set yang akan dijalankan
oleh proses, yaitu berupa software. Program kemudian mengendalikan
semua aktifitas yang ada pada proses. Program berikut berisi konstruksi
logika yang dibuat oleh manusia, dan telah diterjemahkan kedalam bahasa
mesin sesuai dengan format yang ada pada instruction set.
11

12
2.3. Core Banking
Sistem core banking merupakan suatu sistem utama (core) yang
dipergunakan oleh bank untuk melayani seluruh transaksi perbankan yang
terintegrasi antara kegiatan front office (pencatatan transaksi) dan back
office (pemrosesan transaksi) serta memiliki beberapa fungsi sistem
informasi manajemen lainnya, seperti : akuntansi, manajemen dana,
manajemen kredit, dan sebagainya. (Taufik Nizami, 2016)
Sistem core banking tersebut merupakan sistem yang sangat vital dan
wajib dimiliki oleh suatu bank karena mencakup sistem pelaporan dan
informasi yang terpusat dan terpadu. Umumnya sistem core banking terdiri
dari beberapa fungsi atau modul yang saling terintegrasi antara lain modul
kredit (loan), modul dana (deposit), modul akuntansi (general ledger),
modul pengiriman uang (remittance) dan sebagainya. Sistem core banking
juga dirancang untuk dapat dengan mudah diintegrasikan dengan aplikasi
lain seperti consumer banking, corporate banking, treasury, risk
management, dan sebagainya. (Sekundera, 2010)
2.4. BI RTGS
Menurut website resmi bagian penyelenggaraan setelmen Bank
Indonesia, Sistem Bank Indonesia Real Time Gross Settlement (BI-RTGS)
adalah suatu sistem transfer dana elektronik antar peserta dalam dalam mata
uang rupiah dimana penyelesaiannya dilakukan secara seketika dengan per-
transaksi secara individual. BI-RTGS merupakan infrastruktur penting

13
dalam sistem keuangan Indonesia, sebagai satu-satunya sarana transfer dana
elektronik bernilai besar.
Dengan sistem BI-RTGS, peserta pelayanan BI-RTGS melalui
terminal RTGS di tempatnya akan mentransmisikan transaksi pembayaran
ke pusat pengolahan sistem RTGS (RTGS- Central Computer/ RCC) di
Bank Indonesia untuk proses settlement. Jika proses settlement berhasil,
transaksi pembayaran akan diteruskan secara otomatis dan elektronis kepada
peserta penerima. Keberhasilan dalam proses settlement akan tergantung
dari kecukupan saldo peserta pengirim, karena dalam sistem BI-RTGS
peserta hanya dapat diperbolehkan untuk melakukan kredit pada peserta
lain. Dengan kata lain, peserta BI-RTGS harus meyakinkan bahwa saldo
rekeningnya di Bank Indonesia cukup sebelum melaksanakan transfer
kepada peserta BI-RTGS lainnya.
Berikut adalah tujuan dari adanya BI-RTGS :
● Mengurangi risiko penyelesaian akhir (settlement risk) dalam sistem
pembayaran nasional.
● Menyediakan tambahan pilihan sarana transfer yang efisien, cepat,
aman, dan handal.
● Meningkatkan kepastian penyelesaian akhir.
● Meningkatkan efektivitas pengelolaan dana (management fund) bagi
bank melalui sentralisasi Rekening Giro.
● Memberikan informasi yang mendukung kebijakan moneter dan early
warning system bagi pengawasan bank.

14
Saat ini, pada sistem BI-RTGS menggunakan mekanisme gross
settlement, dimana setiap transaksi diperhitungkan secara individual dan
real time. Dengan kata lain settlement transaksi antar peserta dilakukan
secara langsung sepanjang terdapat dana yang cukup. Mekanisme ini
berbeda dengan net settlement dimana proses penyelesaian transaksi
pembayaran dilakukan pada akhir periode dengan melakukan offsetting
antara kewajiban pembayaran dengan hak penerimaan sehingga hanya ada 1
net hak atau kewajiban yang akan di settle untuk setiap masing-masing
rekening peserta. Dengan adanya mekanisme ini, bertujuan untuk
mengurangi risiko gagal bayar peserta yang sebelum adanya sistem RTGS
ini berpotensi pula menjadi risiko sistemik. Risiko sistemik adalah apabila
terdapat transaksi yang nilainya cukup signifikan (high value) seperti valuta
asing dan pengelolaan moneter dilakukan dengan mekanisme net settlement,
dan terjadi kegagalan bayar maka berdampak pada merugikan peserta lain.
2.4.1. Mekanisme Transfer Dana BI-RTGS
Secara umum dapat digambarkan bahwa mekanisme transfer dana
antar peserta BI-RTGS adalah sebagai berikut :
1. Peserta pengirim menginput credit transfer ke dalam terminal RTGS
untuk selanjutnya ditransmisikan ke RCC di bank Indonesia.
2. Selanjutnya, RCC melakukan proses credit transfer dengan mekanisme
sebagai berikut:

15
○ Melakukan checking kecukupan saldo, apakah saldo rekening giro
peserta pengirim lebih besar dari atau sama dengan nilai nominal
credit transfer.
○ Jika saldo rekening giro peserta pengirim mencukupi akan dilakukan
posting secara simultan pada rekening giro peserta pengirim dan
rekening giro peserta penerima.
○ Jika saldo rekening giro peserta pengirim tidak mencukupi, maka
credit transfer tersebut akan ditempatkan dalam antrian (queue)
sistem BI-RTGS.
3. Informasi credit transfer yang telah diselesaikan (settled) akan
ditransmisikan secara otomatis oleh RCC ke RT peserta pengirim dan
RT peserta penerima.
2.5. Swift
Society for Worldwide Interbank Financial Telecommunication
(SWIFT) merupakan sebuah organisasi nirlaba yang dikendalikan oleh
organisasi jaringan banking internasional yang menciptakan layanan
standarisasi pesan jaringan telekomunikasi antar bank dan bertujuan untuk
melakukan pertukaran pesan keuangan dan surat berharga. Swift diciptakan
pada tahun 1973 oleh banking yang membutuhkan sistem efisien dan aman
untuk komunikasi antar bank. Sebelumnya, semua komunikasi antar bank
dilakukan melalui telepon, kurir, atau surat. Sedangkan dalam satu hari bank
harus mengirimkan jutaan pesan yang mengandung informasi sensitif. Oleh

16
karena itu dibutuhkan sebuah pelayanan yang memiliki akses jaringan yang
cepat aman dan rahasia.
Swift telah digunakan oleh lebih dari 8300 bank, sekuritas, dan
perusahaan yang berlokasi pada lebih dari 208 negara. Swift menyediakan
platform dengan basis data yang terpusat untuk bank, perusahaan dan
lembaga keuangan untuk bertukar pesan, dan memungkinkan bank untuk
bekerjasama dengan bank lain di seluruh dunia dengan aman dan handal.
(Ruth, 2018).
Pada gambar 2.1. akan menggambarkan alur pembayaran antar bank
negara menggunakan pesan swift :
gambar 2.1. alur pembayaran lintas negara
sumber : (Ruth, 2018)

17
Pada gambar 2.1. menggambarkan bahwa setiap aliran dana dari 2
negara yang berbeda menggunakan sebuah pesan dengan kode MT-103
sampai transaksi tersebut tiba ke tujuan. Dalam penggunaan Swift, setiap
transaksi atau pertukaran pesan antar bank dalam bentuk apapun memiliki
code pesan masing- masing yang dinamakan dengan Swift Code.
2.5.1. Swift Code
Swift Code merupakan dokumen singkat yang menyediakan nama dan
kode asal bank, nama dan kode bank penerima, jumlah transfer, dan salah
satu kode dari beberapa preset yang memberikan pesan kepada bank
penerima. Pesan berbentuk preset menyediakan kondisi standar untuk
mentransfer pesan/instruksi antar bank. Pesan tersebut harus singkat dan
terbatas pada jumlah karakter tertentu. Hal ini dikarenakan sebuah sistem
bank yang sangat efisien dan pesan ini akan dapat diproses dalam sistem.
Pada Swift Code, setiap transaksi memiliki kode pesan MT (Message
Type) yang terdiri dari MT 100 sampai MT 999. Setiap masing-masing MT
memiliki fungsi yang berbeda, dan dibagi antar tugasnya masing masing.
Pada tabel 2.1. akan menjabarkan setiap tugas antar message type. Dimana
dari 999 macam MT dibagi menjadi 9 tugas yang nantinya akan dipecah
setiap nomornya.
S.W.I.F.T. CUSTOMER TRANSFER AND CHECKS FILE. Message
MT 102 s/d 199 Type (MT.1xx.)
S.W.I.F.T. FINANCIAL INSTITUSI TRANSFER FILE. Message Type
MT 200 s/d 299 (MT.2..)
MT 300 s/d 399 S.W.I.F.T. TREASURY, FOREX FILE. Message Type (MT.3..)

18
S.W.I.F.T. COLLECTION AND CASH LETTER FILE. Message Type
MT 400 s/d 499 (MT.4..)
MT 500 s/d 599 S.W.I.F.T. SECURITIES MARKET FILE. Message Type (MT.5..)
S.W.I.F.T. PRESIOUS METALS AND SINDICATES FILE. Message
MT 600 s/d 699 Type (MT.6..)
S.W.I.F.T. DOCUMENTARY CREDIT AND GUARANTEE FILE.
MT 700 s/d 788 Message Type (MT.7..)
MT 800 s/d 899 S.W.I.F.T. TRAVELLERS CHEQUES FILE. Message Type (MT.8..)
S.W.I.F.T. CASH MANAGEMENT OUR STATUS FILE. Message
MT 900 s/d 999 Type (MT.9..)
Tabel 2.1. Klasifikasi Message Type
Setiap masing masing MT memiliki fungsi yang berbeda. Setiap MT
memiliki tag yang berfungsi sebagai penanda informasi yang tersedia dalam
file MT tersebut. Tag memiliki format dan standar pengisian data seperti tag
20 yang biasa nya digunakan untuk diisi dengan nomor referensi yang
panjang data tidak lebih dari 16 karakter, akan tetapi untuk sebagian MT tag
20 tidak digunakan untuk nomor referensi.
2.6. Metode Pengembangan Sistem
Metodologi pengembangan sistem yang digunakan peneliti dalam
membuat rancangan aplikasi BI-RTGS adalah dengan metode model Rapid
Application Development. RAD melibatkan pengembangan dan
pembangunan prototipe iteratif. Pada tahun 1990, dalam buku RAD, Rapid
Application Development, james martin didokumentasikan penafsirannya
tentang metodologi. Baru-baru ini, istilah dan singkatan yang telah datang

19
untuk digunakan dalam lebih luas, pengertian umum yang mencakup
berbagai metode yang bertujuan untuk mempercepat pengembangan
aplikasi, seperti penggunaan kerangka perangkat lunak dari berbagai jenis,
seperti kerangka kerja aplikasi web.
Pengembangan aplikasi yang cepat merupakan respon terhadap proses
yang dikembangkan pada 1970-an dan 1980-an, seperti struktur sistem
metode analisis dan desain dan model waterfall lainnya. Satu masalah
dengan metodologi sebelumnya adalah bahwa aplikasi begitu lama untuk
membangun bahwa persyaratan telah berubah sebelum sistem itu selesai,
sehingga sistem tidak memadai atau bahkan tidak dapat digunakan. Masalah
lain adalah asumsi bahwa persyaratan metodis tahap analisis saja akan
mengidentifikasi semua persyaratan penting. Membuktikan fakta bahwa ini
adalah jarang terjadi, bahkan untuk proyek-proyek dengan profesional yang
sangat berpengalaman di semua tingkatan.
Menurut Kendall (2010), terdapat tiga tahapan dalam RAD yang
melibatkan penganalisis dan pengguna dalam tahap penilaian, perancangan,
dan penerapan. Adapun ketiga tahap tersebut adalah requirements planning
(perencanaan syarat-syarat), RAD design workshop design (workshop
desain RAD), dan implementation (implementasi). Sesuai dengan
metodologi RAD menurut Kendall (2010), berikut ini adalah tahap-tahap
pengembangan aplikasi dari tiap-tiap fase pengembangan aplikasi.

20
Gambar 2.2 Skema RAD (Kendall 2010)
2.6.1. Tahap Perencanaan Syarat- Syarat
Dalam fase ini, pengguna dan developer bertemu untuk
mengidentifikasikan tujuan-tujuan aplikasi atau sistem serta untuk
mengidentifikasikan syarat-syarat informasi yang ditimbulkan dari tujuan-
tujuan tersebut. Orientasi dalam fase ini adalah menyelesaikan masalah-
masalah perusahaan. Meskipun teknologi informasi dan sistem bisa
mengarahkan sebagian dari sistem yang diajukan, fokusnya akan selalu tetap
pada upaya pencapaian tujuan-tujuan perusahaan (Kendall, 2010). Dari
tahap ini peneliti melakukan beberapa proses, diantaranya :
1. Tahap Workshop Desain RAD
Tahap ini merupakan langkah untuk merancang dan memperbaiki
sistem yang dapat digambarkan sebagai workshop. Penganalisis dan dan
pemrogram dapat bekerja membangun dan menunjukkan representasi
visual desain dan pola kerja kepada pengguna. Workshop desain ini dapat
dilakukan selama beberapa hari tergantung dari ukuran aplikasi yang

21
akan dikembangkan. Selama workshop desain RAD, pengguna merespon
prototipe yang ada dan penganalisis memperbaiki modul-modul yang
dirancang berdasarkan respon pengguna. Apabila seorang
pengembangnya merupakan pengembang atau pengguna yang
berpengalaman, Kendall menilai bahwa usaha kreatif ini dapat
mendorong pengembangan sampai pada tingkat terakselerasi (Kendall,
2010).
2. Tahap Implementasi
Pada tahap implementasi ini, penganalisis bekerja dengan para
pengguna secara intens selama workshop dan merancang aspek-aspek
bisnis dan non-teknis perusahaan. Segera setelah aspek-aspek ini
disetujui dan sistem-sistem dibangun dan disaring, sistem-sistem baru
atau bagian dari sistem di ujicoba dan kemudian diperkenalkan kepada
organisasi (Kendall, 2010).
2.7. Metode Pengumpulan Data
Metode Pengumpulan data merupakan prosedur sistematis dan
merupakan standar untuk memperoleh data yang diperlukan. Pengumpulan
data merupakan suatu proses pengadaan data primer yang diperlukan dalam
melakukan penelitian (Nazir, 2005).
Secara umum, metode pengumpulan data dapat dibagi menjadi tiga
kelompok (Nazir, 2005), yaitu metode pengamatan langsung, metode
dengan menggunakan pertanyaan dan metode khusus. Sedangkan menurut
Jogiyanto (2008), teknik pengumpulan data dalam pengambilan sampelnya

22
dibagi menjadi 7 antara lain teknik observasi, wawancara dan studi waktu
serta gerak (dilakukan secara pengamatan langsung di studi kasus dan di
lapangan), teknik eksperimen dan simulasi (dilakukan secara pengamatan
langsung untuk mendapatkan data laboratorium), teknik survey (dilakukan
untuk mendapatkan data opini individu), teknik delphi (dilakukan untuk
mendapatkan data opini grup), teknik analisis (dilakukan untuk
mendapatkan data arsip primer), teknik pengambilan basis data (dilakukan
untuk mendapatkan data arsip sekunder), teknik model
matematik (dilakukan secara analitikal untuk mendapatkan data logik
periset). Metode pengumpulan data yang digunakan dalam penelitian ini
adalah sebagai berikut:
1. Observasi
Observasi merupakan teknik atau pendekatan untuk mendapatkan
data primer dengan cara mengamati secara langsung obyek datanya
(Jogiyanto, 2008). Sedangkan menurut Nazir (2005), pengumpulan data
dengan observasi langsung atau pengamatan langsung adalah cara
pengambilan data dengan menggunakan mata tanpa ada pertolongan
alat standar lain untuk keperluan tersebut. dari kedua definisi tersebut,
dapat disimpulkan bahwa observasi merupakan teknik untuk
mengambil data dengan menggunakan data visual dengan mengamati
obyek penelitian secara langsung.

23
2. Wawancara
Wawancara merupakan komunikasi dua arah untuk mendapatkan
data dari responden (Jogiyanto, 2008). Wawancara dapat berupa
wawancara personal (tatap muka langsung dengan responden),
wawancara intersep (responden dipilih di lokasi umum), dan
wawancara telepon. Sedangkan menurut Nazir (2005), wawancara
adalah proses memperoleh keterangan untuk tujuan penelitian dengan
cara tanya jawab, bertatap muka antara pewawancara dengan penjawab
atau responden dengan menggunakan alat yang dinamakan interview
guide (panduan wawancara).
3. Studi Pustaka
Studi pustaka merupakan suatu teknik pengumpulan data atau
analisis data dengan cara memperoleh informasi dari penelitian
terdahulu, tanpa memperdulikan sebuah penelitian menggunakan data
primer atau sekunder, apakah penelitian tersebut menggunakan
penelitian lapangan ataupun laboratorium atau museum.
4. Studi Literatur Sejenis
Studi literatur merupakan kegiatan menelusuri literatur yang ada
serta menelaahnya secara tekun. Dengan mengadakan survey terhadap
data yang telah ada, peneliti harus mencari teori-teori yang telah
berkembang dalam bidang ilmu yang diteliti, mencari metode-metode
serta teknik penelitian, baik dalam pengumpulan data atau dalam
analisis data yang pernah dilakukan oleh peneliti-peneliti terdahulu

24
(Nazir, 2005). Selain itu, peneliti juga harus memperoleh orientasi yang
lebih luas dalam permasalahan yang dipilih serta menghindari
terjadinya duplikasi yang tidak diinginkan.
2.8. UML (Unified Modeling Language)
Unified Modelling Language (UML) adalah sebuah “bahasa” yang
telah menjadi standar dalam industri yang digunakan untuk visualisasi,
merancang dan mendokumentasikan sistem piranti lunak. UML
menawarkan sebuah standar untuk merancang model sebuah sistem. Dengan
menggunakan UML dapat dibuat model untuk semua jenis aplikasi piranti
lunak, dimana aplikasi tersebut dapat berjalan pada piranti keras, sistem
operasi dan jaringan apapun, serta ditulis dalam bahasa pemrograman
apapun. Tetapi karena UML juga menggunakan class dan operation dalam
konsep dasarnya, maka lebih cocok untuk penulisan piranti lunak dalam
bahasa berorientasi objek seperti C++, Java, atau VB. NET.
Setiap sistem yang kompleks seharusnya dapat dipandang dari sudut
yang berbeda sehingga mendapatkan pemahaman secara menyeluruh.
Dalam upaya tersebut UML menyediakan 9 jenis diagram yang dapat
dikelompokkan berdasarkan sifatnya yakini statis dan dinamis. Dalam
penelitian ini hanya menggunakan tiga diagram, diantaranya activity
diagram, sequence diagram, dan use case diagram.
1. Use Case Diagram
Use case digunakan untuk membuat model dan menyatakan unit fungsi
atau layanan yang disediakan oleh sistem atau bagian sistem, subsistem

25
atau class ke pemakai. Use case dapat dilingkupi dengan batasan sistem
yang diberi label nama sistem. Use case merupakan sesuatu yang
menyediakan hasil yang dapat diukur pada pemakai atau sistem
eksternal. Berikut adalah karakteristik dari diagram use case:
● Use Case adalah interaksi atau dialog antara sistem dan aktor,
termasuk pertukaran pesan dan tindakan yang dilakukan oleh sistem.
● Use Case diprakarsai oleh aktor dan mungkin melibatkan peran
aktor lain. Use case harus menyediakan nilai minimal pada satu
aktor.
● Use Case dapat memiliki perluasan yang mendefinisikan tindakan
khusus dalam interaksi atau use case lain yang mungkin disisipkan.
● Use case class memiliki objek use case yang disebut skenario,
skenario tersebut menyatakan urutan pesan dan tindakan tunggal.
Gambar 2.3 Contoh Use Case Diagram

26
2. Activity Diagram
Activity Diagram menggambarkan berbagai alur aktivitas dalam sistem
yang sedang dirancang, bagaimana masing-masing alur berawal,
decision yang mungkin terjadi, dan bagaimana akhir dari alur tersebut.
Activity diagram juga dapat menggambarkan proses paralel yang
mungkin terjadi pada beberapa eksekusi.
Gambar 2.4 Contoh Activity Diagram

27
Gambar 2.5 Keterangan Activity Diagram
3. Sequence Diagram
Sequence Diagram merupakan diagram interaksi yang menekankan
pada pengiriman pesan (message) dalam suatu waktu tertentu. Sequence
diagram menjelaskan interaksi objek yang disusun berdasarkan urutan
waktu. Secara mudahnya sequence diagram adalah gambaran tahap
demi tahap yang seharusnya dilakukan untuk menghasilkan sesuatu
sesuai dengan use case diagram.
Gambar 2.6 Contoh Sequence Diagram

28
2.9. Bahasa Pemograman dan Basis Data
2.9.1. Php
PHP (Hypertext Prepocessor) merupakan bahasa pemrograman
dengan bentuk interpreter yang paling banyak digunakan saat ini. PHP
banyak dipakai dalam pembuatan program situs web dinamis yang dapat
digunakan bersamaan dengan HTML. PHP diciptakan oleh Rasmus Lerdorf
pada tahun 1994. Contoh terkenal dari aplikasi PHP adalah forum (phpBB)
dan MediaWiki (software di belakang Wikipedia). PHP juga dapat dilihat
sebagai pilihan lain dari ASP.NET/C#/VB.NET Microsoft, ColdFusion
Macromedia, JSP/Java Sun Microsystems, dan CGI/Perl. Contoh aplikasi
lain yang lebih kompleks berupa CMS yang dibangun menggunakan PHP
adalah Mambo, Joomla!, Postnuke, Xaraya, dan lain lain.
29.2. SQL Server 2008
SQL Server 2008 adalah sebuah DBMS (Database Management
System yang diciptakan oleh Microsoft dengan tujuan untuk ikut serta
dalam persaingan dunia pengolahan data menyusul dengan pendahulunya
seperti IBM dan Oracle.
2.10. Framework
2.10.1. Codeigniter
Codeigniter merupakan sebuah framework dari bahasa pemograman
PHP yang dapat membantu mempercepat developer dalam pengembangan
aplikasi web berbasis PHP dibanding jika menulis semua code program dari
awal. (Basuki, 2010).

29
Codeigniter pertama kali diciptakan oleh Rick Ellis, CEO Ellislab,
Inc. , sebuah perusahaan yang memproduksi CMS (Content Management
System) yang cukup handal, yaitu Expression Engine
(http://www.expressionengine.com). Saat ini Codeigniter dikembangkan
dan dimaintain oleh Expression Engine Development Team. Adapun
beberapa keuntungan menggunakan Codeigniter, diantaranya:
1. Gratis
Codeigniter berlisensi dibawah Apache/BSD open source.
2. Ditulis menggunakan PHP 4
Meskipun Codeigniter dapat berjalan di PHP 5, namun sampai saat ini
kode program Codeigniter masih dibuat dengan menggunakan PHP 4.
3. Berukuran Kecil
Ukuran Codeigniter yang kecil merupakan keunggulan tersendiri.
Dibanding dengan framework lain yang berukuran besar.
4. Menggunakan Konsep MVC
Codeigniter menggunakan konsep MVC yang memungkinkan
pemisahan layer application-logic dan presentation.
5. URL yang sederhana
Secara default, URL yang dihasilkan Codeigniter sangat bersih dan
Seacrh Engine Friendly (SEF).
6. Memiliki Paket Library yang Lengkap
Codeigniter memiliki library yang lengkap untuk mengerjakan operasi
yang umum dan dibutuhkan oleh sebuah aplikasi berbasis web,

30
misalnya mengakses database, mengirim email, melakukan validasi
form, menangani session, dan sebagainya.
7. Extensible
Sistem dapat dikembangkan dengan mudah menggunakan plugin dan
helper, atau dengan menggunakan hooks.
8. Tidak Memerlukan Template Engine
Meskipun Codeigniter dilengkapi dengan template parser sederhana
yang dapat digunakan, tetapi hal ini tidak harus untuk digunakan.
9. Dokumentasi Lengkap dan Jelas
Dari sekian banyak framework, Codeigniter merupakan satu-satunya
framework dengan dokumentasi yang lengkap dan jelas.
10. Komunitas
Komunitas Codeigniter saat ini berkembang pesat.
Proses aliran data aplikasi pada sistem ini dapat diilustrasikan seperti
gambar dibawah ini:
Gambar 2. 7 Application Flowchart
Keterangan :
1. Index.php berfungsi sebagai front controller, menginisialisasi base
resource untuk menjalankan Codeigniter.

31
2. Router memeriksa HTTP request untuk menentukan apa yang harus
dilakukan dengannya.
3. Jika Cache aktif, maka hasilnya akan langsung dikirimkan ke browser
dengan mengabaikan aliran data normal.
4. Security. Sebelum Controller dimuat, HTTP request dan data yang
dikirimkan user akan di filter untuk keamanan.
5. Controller memuat model, core libraries, plugins, helpers, dan semua
resource yang diperlukan untuk memproses request.
6. Akhirnya view yang dihasilkan akan dikirimkan ke browser. Jika cache
aktif, maka view akan disimpan sebagai cache dahulu, sehingga pada
request berikutnya langsung dapat ditampilkan.
2.10.2. Model View Controller
Codeigniter merupakan framework PHP yang dibuat berdasarkan
kaidah model-View-controller. Dengan MVC, maka memungkinkan
pemisahan antara layer application-logic dan presentation. Sehingga, dalam
sebuah pengembangan aplikasi web, seorang programmer dapat
berkonsentrasi pada core-system, sedangkan web designer dapat
berkonsentrasi pada tampilan web. Hal yang menarik adalah script PHP,
query MySQL, Javascript dan CSS dapat saling terpisah dan tidak dibuat
dalam satu script berukuran besar yang membutuhkan resource yang besar
pula untuk mengeksekusinya. (Basuki, 2010). Adapun alur program aplikasi
berbasis framework Codeigniter dapat dilihat pada gambar dibawah :

32
Gambar 2. 8 Model-View-Controller
Gambar diatas menerangkan bahwa ketika sebuah user request datang,
maka akan ditangani oleh controller, kemudian controller akan memanggil
model jika memang diperlukan operasi database. Hasil dari query oleh
model kemudian akan dikembalikan kepada controller. Selanjutnya
controller akan memanggil view yang tepat dan mengkombinasikannya
dengan hasil query model. Hasil akhir dari operasi ini akan ditampilkan
pada browser. Pada konteks Codeigniter dan aplikasi berbasis web, maka
penerapan konsep MVC mengakibatkan kode program dapat dibagi
menjadi tiga kategori, yaitu :
1. Model
Kode program yang digunakan untuk memanipulasi database.
2. View
Berupa template html/xml atau php untuk menampilkan data pada
browser.
3. Controller
Kode program yang digunakan untuk mengontrol aliran aplikasi.

33
2.10.3. Node Js
Node Js merupakan platform server yang dibangun menggunakan
javascript dan berjalan didalam interpreter Chrome Javascript runtime.
diciptakan untuk pengembangan perangkat lunak berbasis web yang cepat
dan aplikasi jaringan yang scalable. Node.js menggunakan event-driven,
model non-blocking I/O yang membuatnya menjadi ringan dan efisien.
Sangat baik digunakan untuk aplikasi real time yang dapat digunakan di
berbagai perangkat.

BAB III
METODOLOGI PENELITIAN
Di dalam melakukan penelitian ini digunakan dua buah metodologi, yaitu metode
pengumpulan data untuk mencari informasi terkait penelitian berdasarkan studi
kasus yang diambil, dan metode pengembangan sistem yang dipakai untuk
mencapai tujuan dari penelitian. Berikut adalah metode yang dipakai adalah
sebagai berikut:
3.1. Metode Pengumpulan Data
Untuk mendapatkan informasi dan data yang dibutuhkan, peneliti
menggunakan beberapa metode pengumpulan data untuk mendapatkan data
dan informasi yang dibutuhkan dalam penelitian, selain itu juga untuk
mendukung materi-materi yang digunakan dalam penelitian.
Adapun beberapa metode pengumpulan data yang digunakan dalam
penelitian, antara lain:
3.1.1. Studi Pustaka
Studi kepustakaan adalah studi yang dilakukan dengan mempelajari
berbagai pustaka yang menyangkut dengan masalah yang akan dibahas
dengan menggali teori-teori yang telah berkembang dalam bidang ilmu yang
berkepentingan, mencari metode-metode serta teknik penelitian, baik dalam
mengumpulkan data atau dalam menganalisis data, yang telah pernah
dipergunakan oleh peneliti-peneliti terdahulu sehingga memperoleh
orientasi yang lebih luas dalam permasalahan yang dipilih dan diangkat
34

35
(Nazir, 2005:12). Dalam hal ini peneliti pembelajaran terhadap tiga jurnal
sejenis yang berkaitan dengan penelitian ini. Sebagai sumber referensi dan
bahan acuan terhadap aplikasi yang akan dibuat dijadikan bahan
pertimbangan dan acuan untuk menghasilkan aplikasi yang lebih baik.
Berikut adalah tabel perbandingan studi literatur sejenis:
No Judul Peneliti, Tahun dan Institusi Hasil Penelitian
Penelitian ini menjelaskan
mengenai bagaimana alur
Mekanisme Transaksi Real Time dari berjalannya transaksi
Gross Settlement (RTGS) pada Salsabil Nadila, 2018, Tugas BI-RTGS dan core
PT. Bank Tabungan Negara Akhir Program Studi Perbankan banking bank peserta BI-
(Persero) Kantor Cabang dan Keuangan Fakultas Ekonomi RTGS pada sebuah bank
1 Pembantu Syariah Yogyakarta Universitas Islam Indonesia syariah di Indonesia.
bagaimana proses
transaksi realtime
settlement
diimplementasikan secara
internasional
The Future of Correspondent Ruth Wandhover, 2018, SWIFT menggunakan format
2 Banking Cross Border Payments Institute bahasa SWIFT
A Proposal for a Decentralized
Liquidity Savings Mechanism Adam Fugal, 2018, Singapore
3 With Side Payments Management University
tabel 3.1. Studi Literatur Sejenis

36
3.1.2. Studi Lapangan
1. Wawancara
Wawancara merupakan teknik penelusuran fakta, dimana analis
sistem mengumpulkan informasi dari tiap individu, melalui interaksi
face to face (Whitten & L, 2004). Hal ini dilakukan dengan tujuan untuk
memperoleh informasi selengkap-lengkapnya tentang penerapan aplikasi
interface dan integrasi BI-RTGS tersebut.
Dalam metode wawancara ini, peneliti akan melakukan wawancara
dengan seorang vendor IT engineer yang bertanggung jawab dalam
pengembangan aplikasi interface BI-RTGS.
Tempat : Bank DKI
Nama : Radot Regen Sihombing
Alamat : Jl. Ir. H. Juanda III no.7-9 Gambir, Jakarta Pusat,
Daerah Khusus Ibukota Jakarta, 10120
Waktu : 13 Juni 2017
Dari wawancara tersebut, didapatkan rincian masalah dan solusi
yang harus diterapkan dalam pengembangan aplikasi interface dan
integrasi BI-RTGS Gen II.
2. Observasi
Observasi dilakukan untuk mengetahui bagaimana proses transaksi
transfer RTGS berjalan dari tahap channel hingga tahap core banking
hingga diteruskan ke tahap BI-RTGS.

37
3.2. Metode Pengembangan Sistem
Dalam perancangan aplikasi interface dan integrasi BI-RTGS ini,
peneliti menggunakan metode pengembangan aplikasi sistem pengembangan
perangkat lunak RAD (Rapid Application Development). Penggunaan metode
ini diterapkan karena sangat cocok dalam pengembangan aplikasi ini dengan
alur dan runtutan yang jelas dan cepat disertai dengan modul design yang
mudah dipahami oleh pengguna.
3.1.1. Tahap Perencanaan Syarat-Syarat
Dalam tahap ini, pengguna dan peneliti bertemu untuk
mengidentifikasikan tujuan dari pengembangan sistem ini beserta
mengidentifikasi syarat informasi yang ditimbulkan dari tujuan
tersebut. Orientasi dalam fase ini adalah menyelesaikan masalah yang
ada. Meskipun teknologi informasi dan sistem dapat mengarahkan
sebagian dari sistem yang diajukan, fokusnya akan selalu tetap pada
upaya pencapaian tujuan-tujuan perusahaan. Dalam tahap ini
dilakukan beberapa proses, diantaranya :
1. Mengidentifikasi Tujuan Sistem
● Analisa Sistem
Pada proses ini akan menjelaskan mengenai analisis sistem
yang sebelumnya berjalan meliputi kelemahan sistem lama
yaitu BI-RTGS Gen 1, sehingga diperlukan adanya
peningkatan dan penyempurnaan dalam pengembangan
aplikasi interface dan integrasi BI-RTGS gen II

38
● Analisa Sistem Berjalan
Pada proses ini akan memberikan gambaran dan sistem yang
sudah berjalan pada sistem perbankan untuk melakukan
transaksi BI-RTGS.
● Sistem Usulan
Pada proses ini akan memberikan gambaran mengenai
penjelasan sistem yang akan dirancang sesuai dengan masalah
yang dihadapi oleh bank peserta BI-RTGS karena adanya
pembaruan sistem ini.
2. Mengidentifikasi Syarat- Syarat Informasi
1. Identifikasi Masalah
Identifikasi Masalah dilakukan dengan melakukan analisa
kebutuhan masalah dalam pembuatan aplikasi dengan
melibatkan dua belah pihak antara penulis dengan pengguna.
Tahap ini berguna untuk mengidentifikasi syarat-syarat yang
akan dipenuhi.
3.2.1. Tahap Workshop Desain RAD
Pada tahap ini, analis dan programmer dapat bekerja
membangun dan menunjukkan representasi visual desain dan pola
kerja kepada user. Workshop desain ini dapat dilakukan selama
beberapa hari tergantung dari ukuran aplikasi yang akan
dikembangkan. Selama workshop desain RAD, pengguna merespon
prototipe yang ada dan analis memperbaiki modul yang dirancang

39
berdasarkan respon pengguna. Pada tahap ini terdiri dari beberapa
proses, diantaranya :
1. Desain Model UML
Yaitu proses seorang analis melakukan pembuatan alur desain
model aplikasi dengan membuat modul yang dibentuk di dalam
sebuah diagram sebagai acuan dalam membangun aplikasi
interface dan integrasi BI-RTGS Gen II. Adapun UML (Unifield
Modeling Languange) di buat pada penelitian ini adalah Activity
Diagram, Class Diagram, Squence Diagram, Usecase Diagram.
2. Pembangunan Konstruksi Sistem
Pada tahap ini dilakukan pengkodean terhadap rancangan
yang telah didefinisikan dari proses desain sistem. Seperti
pembuatan database, penerapan coding program sampai dengan
selesai.
3.2.2. Tahap Implementasi
Pada tahap implementasi, analis dan user bekerja secara intens
selama workshop dan merancang aspek-aspek bisnis dan non teknis
perusahaan. Segera setelah aspek ini disetujui dan sistem
dikembangkan dan diuji coba, kemudian diperkenalkan kepada
perusahaan. Pembahasan pada tahap implementasi meliputi perangkat
yang digunakan, pembuatan sistem, instalasi sistem, pengoperasian
sistem dan pengujian sistem yang dibuat yaitu aplikasi interface dan
integrasi BI-RTGS Gen II. Hal ini mengacu kepada rumusan masalah

40
yang ada dan kesemuanya berkaitan dengan pengujian yang
menekankan pada fungsionalitas dari aplikasi yang dibuat.
3.2.3. Kerangka Penelitian
Dalam melakukan penelitian ini, peneliti melakukan beberapa
tahapan kegiatan dengan mengikuti rencana kegiatan yang telah
tertulis didalam kerangka penelitian. Dalam kerangka penelitian ini
meliputi metode pengumpulan data dan metode pengembangan
sistem.
Gambar 3.1 Kerangka Penelitian

BAB IV
ANALISIS, PERANGANCAN, DAN IMPLEMENTASI
4.1. Pengumpulan Data
4.1.1. Observasi
Peneliti melakukan observasi langsung ke salah satu bank peserta
pada saat melakukan magang di suatu perusahaan solusi teknologi informasi
yang ada di jakarta. saat itu perusahaan ini sedang mengembangkan aplikasi
interface BI-RTGS di bank peserta. dalam kegiatan magang peneliti
melakukan observasi dan mengetahui bagaimana metode dan flow sistem
RTGS yang berjalan di bank peserta tersebut dari awal channel melakukan
transaksi sampai ke core banking dan diteruskan ke sistem BI-RTGS.
4.1.2. Wawancara
Tahap wawancara ini ditujukan kepada salah seorang vendor IT
engineer pada sebuah bank peserta BI-RTGS, yaitu Radot Regen
Sihombing, yang merupakan salah satu karyawan vendor yang mengerjakan
sebuah proyek pengembangan aplikasi interface dan integrasi BI-RTGS Gen
II. Pengumpulan data menggunakan teknik wawancara ini adalah untuk
mendapatkan informasi format messaging yang sudah tersedia pada bank
peserta tersebut agar dapat dipetakan menjadi format messaging BI-RTGS
Gen II beserta kebutuhan fitur yang ada pada aplikasi interface yang
diinginkan oleh bank peserta BI-RTGS.
41

42
4.1.3. Studi Pustaka
No Judul Peneliti, Tahun dan Institusi Hasil Penelitian

mengenai bagaimana alur
Mekanisme Transaksi Real Time dari berjalannya transaksi
Gross Settlement (RTGS) pada Salsabil Nadila, 2018, Tugas BI-RTGS dan core
PT. Bank Tabungan Negara Akhir Program Studi Perbankan banking bank peserta BI-
(Persero) Kantor Cabang dan Keuangan Fakultas Ekonomi RTGS pada sebuah bank
1 Pembantu Syariah Yogyakarta Universitas Islam Indonesia syariah di Indonesia.
bagaimana proses
transaksi realtime
settlement
diimplementasikan secara
internasional
The Future of Correspondent Ruth Wandhover, 2018, SWIFT menggunakan format
2 Banking Cross Border Payments Institute bahasa SWIFT
mengenai solusi keamanan
dalam penyaluran dana
elektronik dengan cara
melakukan sentralisasi
dimana setiap terjadi
pertukaran file / transaksi
Centralized Solution to Securely antara pihak Lembaga
Transfer Payment Information Manu Kohli dan Edgardo Suarez, keuangan dan perusahaan
Electronically to Banks for 2016, International Conference dapat termonitor dengan
3 Multiple ERP Systems on Information Technology baik.
Tabel 4.1. Studi Literatur Sejenis
4.2. Tahap Perencanaan Syarat-Syarat
4.2.1. Identifikasi Masalah
Berdasarkan hasil observasi yang dilihat dari salah satu bank peserta
BI-RTGS, peneliti melihat bahwa hampir semua sistem yang telah berjalan
pada berbagai channel transaksi bank peserta BI-RTGS masih menggunakan
format lama, dimana semua channel memiliki data master masing-masing.
Selain itu, channel untuk kode transaksi masih menggunakan kode transaksi
TRN dan juga masih menggunakan core banking dengan format yang sama.

43
Hal ini sudah jelas tidak dapat digunakan lagi karena BI-RTGS telah
menggunakan format yang baru yaitu menggunakan format MT yang biasa
digunakan pada format swift code messaging.
Sehingga bank peserta yang ingin tetap menjalankan transaksi BI-
RTGS harus melakukan manual transaksi dengan melakukan validasi di
core banking. Apabila transaksi yang masuk ke core banking adalah
transaksi RTGS, maka pada sistem core banking akan di hold atau
digagalkan dengan memutuskan koneksi dari jaringan server core banking
ke jaringan server BI-RTGS. Selanjutnya operator dari bank tersebut akan
melihat informasi gagal tersebut di core banking lalu melakukan input
manual data di aplikasi BI-RTGS yang disediakan BI dan juga sebaliknya
jika ada incoming masuk dari BI-RTGS Gen II maka operator harus selalu
mengecek transaksi tersebut agar dapat di input ke core banking secara
manual.
Dari hal tersebut jelas menyulitkan operator untuk memenuhi standar
operasional yang ditetapkan oleh BI yaitu jika transaksi yang masuk ke
sistem BI-RTGS bank peserta diwajibkan melakukan transaksi tersebut
selambat-lambat nya satu jam setelah transaksi diterima. jika terlambat
maka bank peserta akan di denda sesuai ketentuan yang berlaku.
4.2.2. Analisa Sistem
Proses transaksi transfer RTGS ini masih menggunakan interaksi
operator untuk melakukan manual input di aplikasi yang disediakan oleh BI-
RTGS. Dampaknya, operator akan mengalami kesulitan untuk memenuhi

44
standar operational karena dalam 1 hari transaksi RTGS bisa mencapai 500
transaksi untuk transaksi yang masuk maupun keluar. Karena proses input
yang masih manual ini beresiko untuk mengalami error karena kesalahan
input yang manual tersebut.
Mengacu pada kendala-kendala yang sudah dipaparkan di atas, maka
bank peserta BI-RTGS membutuhkan sistem yang menjadi penghubung
core banking mereka dengan BI-RTGS Gen II agar transaksi mereka tetap
bisa berjalan dengan otomatis dan mengurangi keterlibatan operator.
4.2.3. Analisa Sistem Berjalan
Gambar 4.1. Skema Sistem Berjalan
Berikut uraian sistem berjalan
1. Nasabah akan membuka salah satu channel yang tersedia pada bank
peserta RTGS, selanjutnya nasabah memilih menu transfer RTGS lalu

45
channel akan melakukan permintaan transaksi RTGS ke server core
banking.
2. Core banking menerima permintaan channel lalu membuat format
messaging RTGS untuk dikirim ke aplikasi BI-RTGS namun karena
koneksi dari server core banking ke server BI-RTGS ditutup maka
transaksi ini gagal/hold.
3. Operator akan selalu melakukan monitoring transaksi yang masuk dan
memastikan bahwa ini merupakan transaksi RTGS jika iya maka
operator melihat data permintaan dan menginput data tersebut di
aplikasi BI-RTGS.
4. BI-RTGS mengirim file transaksi masuk/incoming ke sistem bank
peserta.
5. Operator akan selalu melihat transaksi yang masuk dari BI-RTGS dan
melihat data yang masuk di sistem BI-RTGS untuk di input ke core
banking agar core banking dapat melakukan pendebetan ke rekening
nasabah.

46
4.2.4. Sistem Usulan
Gambar 4.2. Skema Sistem Usulan
Berikut uraian sistem usulan :
1. Nasabah akan membuka salah satu channel yang tersedia pada bank
peserta RTGS, selanjutnya nasabah memilih menu transfer RTGS lalu
channel akan melakukan permintaan transaksi RTGS ke server core
banking.
2. Core banking menerima permintaan channel lalu membuat format
messaging RTGS untuk dikirim ke aplikasi interface.
3. Interface menerima format messaging RTGS format lama dari core
banking akan memetakan format tersebut lalu membuat format
messaging RTGS Gen II yang akan dikirim ke BI-RTGS lalu
mengirimnya.

47
4. BI-RTGS mengirim file transaksi masuk/incoming ke sistem bank
peserta.
5. Interface menerima file messaging/transaksi masuk/incoming lalu
memetakan format tersebut dan membuat format messaging yang bisa
dibaca oleh core banking lalu mengirimnya.
6. Core banking menerima format messaging dari interface lalu
melakukan pendebetan ke rekening yang dituju.
4.3. Tahap Workshop Design
Pada tahap ini penulis melakukan beberapa perancangan untuk
pembuatan sistem interface yang bisa menunjang komunikasi antara sistem
BI-RTGS Gen II dengan core banking yang masih menggunakan format
messaging sistem lama.
a. Sebelum melakukan pembuatan sistem interface ini hal pertama yang
perlu dilakukan adalah mempelajari data apa saja yang ada di sistem
core banking dan sistem BI-RTGS Gen II dan cara interface
berkomunikasi dengan kedua sistem tersebut.
b. Yaitu dari core banking memiliki format fixed length dengan spesifikasi
tertentu dalam bentuk file text dan akan diletakan di folder tertentu jika
ada outgoing/keluar begitu juga dengan incoming/masuk core banking
akan mengambil file transaksi dengan format fixed length dalam folder
tertentu yang akan dilakukan debet ke rekening tujuan.

48
c. Untuk transaksi incoming/masuk bank peserta menginginkan proses
inquiry/pertanyaan ke server core banking dengan menggunakan format
messaging fixed length untuk pengecekan rekening tujuan.
4.3.1. Outgoing File Core banking
Outgoing File adalah file yang akan dihasilkan oleh core banking
untuk melakukan transaksi transfer ke BI-RTGS yang akan dipetakan oleh
interface untuk menghasilkan format messaging yang dibutuhkan oleh BI-
RTGS Gen II.
File Specification
File Name : OTRTGS _YYYYMMDD_HHMMSS
Type : Batch file, plain text
Format : Fixed length
Field Description Length Remarks
File Header =(38)=
Record Type 1 Fix value : “0”
Member code 17 Fix value, Member Code of Bank
Creation Date 8 Wajib diisi YYYYMMDD. Harus sama
dengan value date
Batch Reference 10 Wajid diisi. Alphanumerik. berisikkan kode
unik dalam 1 hari.
Message type 1 Fix value : “I”
Batch type 1 Fix value : “1”
File Trailer =(47)=

49
Total Credit Count 5 Wajib diisi. Digits, with leading zeroes.
Total Credit Amount 18 Wajib diisi. Digits, 16+2 (without comma
separator), with leading zeroes.
Total Debit Count 5 Fix value : “00000”
Total Debit Amount 18 Fix value : “000000000000000000”
Transaction Record =(1004)=
Transaction code 3 Fix value : “600”
From Member 17 Fix value,Member Code of Bank :
“MUABIDJA”
To Member 17 Wajib diisi. Member Code of beneficiary
bank (example : CENAIDJA, BMRIIDJA)
Receiving Bank Br / Sub-Br 6 Optional (blank)
Code
TRN 8 Wajib diisi. One of the following:
IFT00000
IFTNA000
IFTRJ000
IFTMM000
IFTMM001
IFTFX000
IFTFX001
IFTPL000
Rel TRN 16 Wajib diisi (Generate by system, format : 3
digit Branch code+ 13 digit unique number)

50
Total Amount 17 Wajib diisi. Digits, 15+2 (without comma
separator), with leading zeroes.
Value Date 8 Wajib diisi. YYYYMMDD
Field Name Length Remarks
Sender’s Ref. No. 16 Wajib diisi, fill by user or generate by
system
Receiver’s Ref. No. 16 Optional (blank)
Deal Code / Stock Code 16 Optional (blank)
To Account Number 24 Optional (blank),
To Account Name 140 Wajib diisi,Name of Beneficiary bank
(Destination)
From Account Number 24 Wajib diisi, Fix : “525147000” Number Bank
of BMI
From Account Name 140 Name of bank branch & address(Example:
BMI Branch Jakarta, BMI Branch Medan)
Payment Details 96 Optional, Fill with Narative/description
transaction
Member Info 96 Wajib diisi. Fix Value :
/FEAB/R/PTR/LOCAL
Originating Name 140 Wajib diisi,Name of Originating name
Ultimate Beneficiary 24 Wajib diisi,Account Number Destination
Account (beneficiary)
Ultim ate Beneficiary Nam e 140 Wajib diisi , Name of Customer Beneficiary
Currency 3 Optional (blank) for other TRNs but
Wajib diisi for following TRNs only:

51
IFTFX000
Must conforms to table of Currency Codes in
RTGS
Exchange Rate 7 Optional (blank or zeroes) for other TRNs
but
IFTFX000
Digits, 5.2 (without comma separator), with
leading zeroes
Interest Rate 7 Optional (blank or zeroes) for other TRNs
but
IFTMM000
IFTMM001
IFTPL000
Digits, 3.4 (without comma separator), with
leading zeroes
Period 2 Optional (blank or zeroes) for other TRNs
but
IFTMM000
With leading zero
SAKTI Number 20 Blank

52
Format File Name Outgoing :
OTRTGS _YYYYMMDD_HHMMSS.TXT
Example:
OTRTGS _20110720_110213.TXT
Tabel 4.1. Outgoing messaging spesification bank peserta
4.3.2. Incoming File Core banking
Incoming RTGS adalah file yang akan dihasilkan oleh aplikasi
interface untuk melakukan posting ke core-banking yang akan melakukan
debit ke rekening tujuan. Data incoming ini berasal dari BI-RTGS Gen II.
Proses incoming RTGS terdiri dari :
1. Inquiry RTGS File
Proses inquiry/pertanyaan dari interface ke core banking, Interface akan
meletakan file kedalam folder (Direktori: INREK) dan core banking
akan mengambil file tersebut dengan penjadwalan otomatis.
File Specification
File Name : IQRTGS_YYYYMMDD_HHMMSS
Detail =(24)=

53
Account Number 24 Wajib diisi , “diisi dengan nomor akun dan
diisi dengan 3 digit kode cabang”
Format File Name Inquiry RTGS:
IQRTGS_YYYYMMDD_HHMMSS.TXT
Example:
IQRTGS _20120802_110213.TXT
Tabel 4.2. Inquiry Messaging Specification
2. Respond Inquiry RTGS File
Proses respon inquiry/pertanyaan dari core banking ke interface
core banking (CB) akan meletakan file dalam folder (Direktori: outrek)
File Specification
File Name : RERTGS_YYYYMMDD_HHMMSS
Detail =(24)=
Account Number 24 Wajib diisi , berdasarkan nomor rekening
Full Name of Account 60 Nama yang didapat dari Bi-RTGS

54
Status Account 20 Jika success akan diisi:
0000Successfull
jika akun tidak aktif/dorma akan diisi:
8044Inactive Account
Jika akun tidak ada atau tidak benar akan
diisi:
8035Invalid Account
Jika akun tutup akan diisi:
8045Closed Account
Format File Name Respond Inquiry RTGS:
RERTGS_YYYYMMDD_HHMMSS.TXT
Example:
RERTGS _20120802_110213.TXT
Tabel 4.3. Respond Inquiry RTGS File
3. Incoming RTGS File
Proses transaksi incoming/masuk untuk di posting ke core banking. core
banking akan mengambil transaksi dengan penjadwalan otomatis dalam

55
folder (Directory : in)Format incoming/masuk berbeda karena ada
tambahan 1 field dibaris terakhir.
File Specification
File Name : IN_YYYYMMDD_HHMMSS
Format : Fixed
Field Name Length Remarks
File Header =(37)=
Record Type 1 Fix value : "0"
Member Code 17 Fix value, kode bank peserta
Creation Date 8 Value date : YYYMMDD
Batch Reference 10 harus diisi dengan nomor referensi yang ada
di messaging RTGS
Message Type 1 Fix value : "O"
File Trailer =(47)=
Record Type 1 fixed value"9"
Total Credit Count 5 Digits, dengan nol di depan
Total Credit Amount 18 Digits, 16+2 (tanpa koma), dengan nol
didepan.
Total Debit Count 5 dengan nol di depan
Total Debit Amount 18 Digits, 16+2 (tanpa koma), dengan nol
didepan.
Transaction Record =(1031)=

56
Record Type 1 Fix value : "1"
Transaction Code 3 607 – Single Credit confirmation advice
BOR 6 BOR number
URN Info 14 RCC reference number, consists of :
Date YYYYMMDD + URN (6 digits)
Auth Error Flag 1 "Y" / "N" or blank
OSN 6 OSN number
From Member 17 kode bank peserta pengirim
To Member 17 Fix value, kode bank peserta penerima
Receiving Bank Br / Sub-Br 6 string kosong
Code
TRN 8 TRN
Rel TRN 16 Optional. nomor referensi dari bank
pengirim
Total Amount 17 Digits, 15.2(tanpa koma), dengan nol
didepan..
Value Date 8 YYYYMMDD
Sender’s Ref. No. 16 Optional (blank)
Receiver’s Ref. No. 16 Optional (blank)
Deal Code/Stock Code 16 Optional (blank)
From Account Number 24 Optional (blank)
From Account Name 140 Bank pengirim dan alamat
To Account Number 24 Wajib diisi
To Account Name 140 Nama dan alamat bank penerima
Payment Details 96 Optional (blank)
Member Info 96 Wajib diisi.

57
/FEAB/R
/PTR/LOCAL
Or
/FEAB/NR
/PTR/LOCAL
Originating Name 140 Optional (blank). berasal dari nama yang
ada dari bank pengirim
Ultimate Benef Account 24 diisi dengan nomor rekening nasabah
penerima di tambah 3 digit kode cabang.
Ultimate Benef Name 140 Optional (blank).
Currency 3 Optional (blank) untuk kode TRN yang lain
tapi
Wajib diisi hanya untuk TRN:
IFTFX000
Harus sesuai dengan tabel kode mata uang
dalam RTGS
Exchange Rate 7 Optional (kosong atau nol) untuk TRN lain
tetapi
Wajib puas untuk mengikuti TRN saja:
IFTFX000
Digit, 5.2 (tanpa pemisah koma), denganl
nol di depannya
Interest Rate 7 Optional (kosong atau nol) untuk TRN lain
tetapi
IFTMM000

58
IFTMM001
IFTPL000
Digit, 3.4 (tanpa pemisah koma), dengan
nol didepannya
Period 2 Optional (kosong atau nol) untuk TRN lain
tetapi
IFTMM000
dengan nol didepannya
SAKTI Number 20 Blank
Transaction Status 1 Nilai "0" untuk valid (masuk normal, mis:
kredit ke akun)
Nilai "1" untuk tidak valid (dikreditkan ke GL
Suspend Branch)
Nilai "2" untuk tidak valid (dikreditkan ke GL
Return RTGS)
Format File Name Incoming:
IN_YYYYMMDD_HHMMSS.TXT
Example:
IN_20110804_143358.TXT

59
Tabel 4.4. Incoming RTGS File
4. Respon Status Posting Incoming RTGS
Proses mengirim status posting dari core banking(CB) ke interface. core
banking akan meletakan file respon dalam folder (Directory:out)
File Specification
File Name : RCRTGS_YYYYMMDD_HHMMSS
Detail =(24)=
Date of transaction 8 Wajib diisi , Format : DDMMYYYY
BOR 6 Tergantung BOR Number
Status Account 1 Jika berhasil posting diisi:
“1”
Jika gagal posting diisi:
“0”
Format File Name Respond Inquiry RTGS:
RCRTGS_YYYYMMDD_HHMMSS.TXT
Example:

60
RCRTGS _20120802_110213.TXT
Tabel 4.5. Respon Status Posting Incoming RTGS
4.3.3. Pengenalan MT BI-RTGS GEN II
MT103 adalah salah satu format pesan yang ada pada Swift akan
digunakan untuk komunikasi antar bank yang berfungsi sebagai pesan untuk
melakukan pendebetan di rekening nasabah bank penerima. sebagai contoh
jika A ingin mengirim uang kepada teman saya yang berbeda bank dengan
saya. maka bank saya akan mengirim format pesan MT103 untuk dikirim
ke BI-RTGS lalu diteruskan ke bank teman saya agar bank teman saya
melakukan pendebetan di rekening teman saya. Berikut tabel format tag
untuk MT 103:
Tag keterangan Contoh
20 Nomor referensi 37401111559737
23B Fixed data CRED
23E Fixed data SDVA
32A Tanggal format 80925IDR185000000,00

YYMMDD, mata
uang(IDR), Amount

61
50K Nomor rekening /035601000935301

nasabah pengirim dan PERUM JAMKRINDO
nama serta alamat JL. ANGKASA B9 KAV 6
:53A: D untuk debet C untuk /D/520002000990

kredit , Nomor rekening BRINIDJA
, kode bank penerima
57A D untuk debet C untuk /C/524111000990

kredit , Nomor rekening BDKIIDJ1
, kode bank pengirim
59 Nomor rekening /12292217025

nasabah penerima dan SS Kredit Konsumtif
nama serta alamat :70:Klaim Bank DKI Cempaka Mas an
Sri Endarwati
71A Fixed data OUR
72 Fixed data /CODTYPTR/100

/CLRC/0020307
77B Fixed data /FEAB/R

/PTR/LOCAL/
Tabel 4.6. Format MT103 untuk BI-RTGS

62
Gambar 4.6. Contoh file MT103 untuk BI-RTGS
MT199 ,MT196 dan MT900 adalah format pesan yang digunakan
untuk tujuan informasi yang berkenaan dengan transaksi seperti MT199
bahwa pesan ini berisi sebuah laporan bahwa transaksi tidak dilaksanakan
oleh bank tujuan karena alasan penolakan tertentu misalnya nomor rekening
tujuan tidak ada di bank tujuan dan MT196 dan MT900 adalah format pesan
yang menyatakan bahwa transaksi sudah sukses dilakukan di bank tujuan.
Tag keterangan Contoh
20 nomor referensi dari BI-RTGS/kode MT 973340341/900
21 Nomor referensi dari transaksi yang error 101984702735
25 Kode bank penerima transaksi 524111000990
32A tanggal format YYMMDD, mata 180925IDR729166667

uang(IDR), Amount

63
72 Informasi sistem ESETDATE/1809251252+0000

/OID/180925BDKIIDJ1RST100
01080438
Tabel 4.7. Format MT900 untuk BI-RTGS
Gambar 4.3. Format MT900 untuk BI-RTGS
4.3.4. Desain UML
1. Use Case Diagram
Dibawah ini adalah Diagram Use Case yang menggambarkan
interaksi antara pengguna dan sistem. Berikut ini merupakan langkah
dalam pembuatan Diagram Use Case, diantaranya :
a) Identifikasi Aktor
Dibawah ini merupakan identifikasi aktor yang terlibat didalam
aplikasi interface dan integrasi BI-RTGS.
No Nama Aktor Deskripsi
1 Admin Pada aktor ini, dapat mengakses seluruh menu

yang ada pada sistem, selain itu aktor ini dapat
membuat user baru dan management setting

64
2 Operator Operator dapat melakukan validasi terhadap

transaksi yang terhold karena sesuatu yang tidak
wajar atau validasi sistem dan melakukan
permintaan approval.
3 Supervisor bisa melihat semua kegiatan transaksi dan

memberikan persetujuan dari validasi operator
terhadap transaksi.
Tabel 4.8. Identifikasi Aktor
b) Identifikasi Use Case
Dibawah ini merupakan tabel Identifikasi Use Case. Dalam diagram
use case ini dibagi menjadi beberapa menu dan sub menu,
diantaranya menu monitoring, dashboard dan setting. Dalam menu
monitoring dibagi lagi menjadi transaksi ongoing dan incoming.
Dalam setiap menu dan sub menu memiliki beberapa aktor yang
bertugas untuk mengakses, merubah, dan menerima aproval maupun
disaproval.

65
1. Menu Monitoring
No Use Case Aktor Deskripsi
1 Login Operator, Use case ini menggambarkan kegiatan
Supervisor Login dengan username dan password
2 Hold Operator Use case ini menggambarkan kegiatan
untuk melihat transaksi yang terhold
karena hal yang tidak wajar atau
validasi sistem.
3 GFIT Hold Operator Use case ini menggambarkan kegiatan
untuk melihat transaksi tipe mt202
atau transaksi dari instansi ke instansi.
4 Request Operator Use case ini menggambarkan kegiatan
untuk melakukan action tertentu
terhadap transaksi yang di hold,
seperti pengembalian dana ke
rekening asal, atau membuang
transaksi dari sistem berjalan, atau
melanjutkan transaksi ini
membutuhkan action dari supervisor

66
5 Waiting Supervisor Use case ini menggambarkan kegiatan
Approval pemberian persetujuan atas apa yang
di lakukan operator terhadap transaksi
yang terhold.
Tabel 4.9. Identifikasi Use Case Monitoring Incoming
Gambar 4.3. Use Case Monitoring Incoming

67
2. Approval

Supervisor Login dengan username dan password
2 Hold Operator Use case ini menggambarkan kegiatan

untuk melihat transaksi yang terhold
karena hal yang tidak wajar atau
validasi sistem.
3 Request Operator Use case ini menggambarkan kegiatan

untuk melakukan action tertentu
terhadap transaksi yang di hold atau
membuang transaksi dari sistem
berjalan, atau melanjutkan transaksi
ini membutuhkan action dari
supervisor
4 Waiting Supervisor Use case ini menggambarkan kegiatan
Approval untuk melakukan action tertentu
terhadap transaksi yang di hold,
seperti pengembalian dana ke
rekening asal, atau membuang
transaksi dari sistem berjalan, atau
melanjutkan transaksi ini
membutuhkan action dari supervisor.

68
5 Request Retur Operator Use case ini menggambarkan kegiatan
untuk melakukan kegiatan permintaan
pengembalian dana yang telah dikirim
ke BI-RTGS yang sudah
mendapatkan notifikasi sukses.
kegiatan ini membutuhkan
persetujuan dari supervisor.
Tabel 4.10. Identifikasi Use Case Monitoring Outgoing
Gambar 4.4. Use Case Monitoring Outgoing

69
3. Menu Dashboard
Supervisor, Login dengan username dan password
Admin
2 View Operator, Use case ini menggambarkan kegiatan
Transaction Supervisor, untuk melihat informasi transaksi
Summary Admin incoming dan outgoing per hari ini
3 Connection Operator, Use case ini menggambarkan kegiatan
Status Supervisor, untuk melihat informasi koneksi
Admin status dari interface ke sistem core
banking dan BI-RTGS
4 Pie Chart Operator, Use case ini menggambarkan kegiatan
Supervisor, untuk melihat informasi berupa
Admin diagram transaksi incoming dan
outgoing per hari ini
Tabel 4.11. Identifikasi Use Case Dashboard

70
Gambar 4.5. Use Case Dashboard
4. Menu Setting
1 Login Admin Use case ini menggambarkan kegiatan
Login dengan username dan password
2 System Admin Use case ini menggambarkan kegiatan
Configuration untuk melakukan konfigurasi sistem

71
Form seperti melakukan kegiatan
mengakhiri hari atau memulai hari
untuk menjalankan sistem ini
3 Account Admin Use case ini menggambarkan kegiatan
Blacklist untuk melakukan input data master
untuk kegiatan black list transaksi
berdasarkan rekening, nama , alamat
nasabah dll
4 Amunt Admin Use case ini menggambarkan kegiatan
Capping untuk melakukan edit data master
batas maksimal per transaksi
5 File Folder Admin Use case ini menggambarkan kegiatan
Form untuk kegiatan ini untuk melakukan
edit configurasi folder messaging
yang akan di gunakan untuk
komunikasi antara interface dengan
core banking dan BI-RTGS
6 Priority Admin Use case ini menggambarkan kegiatan
untuk melakukan input data macam-
macam kategory prioritas
Tabel 4.12. Identifikasi Use Case Setting

72
Gambar 4.6. Use Case Setting

73
5. Activity Diagram
1. Activity Diagram Proses Incoming
Gambar 4.7. Activity Diagram transaksi incoming
Aktifitas diatas menjelaskan tentang bagaimana alur proses
incoming berjalan, dimulai dari proses permintaan yang dikirim dari
sistem BI-RTGS kemudian dilakukan converting menggunakan
aplikasi interface. Selanjutnya apabila pada incoming transaksi tidak
terjadi masalah apapun, maka akan langsung dikirimkan ke sistem
core banking untuk dilakukan posting transaksi. Namun apabila terjadi
kesalahan maka sistem akan melakukan hold transaction dimana
operator akan memeriksa transaksi tersebut untuk dilakukan validasi.
Validasi transaksi tersebut terdiri dari tiga pilihan diantaranya request
return, request release, dan request to drop. Selanjutnya Operator
akan mengirimkan request tersebut kepada supervisor untuk
ditindaklanjuti.

74
2. Activity Diagram Proses Outgoing
Gambar 4.8. alur Activity diagram untuk transaksi Outgoing
Pada aktifitas diatas menjelaskan mengenai proses outgoing
berjalan. Proses ini dimulai dari sistem core banking yang
mengirimkan request outgoing transaksi kepada aplikasi interface dan
integrasi BI-RTGS. selanjutnya apabila request outgoing berhasil
tanpa ada masalah maka akan langsung dikirimkan ke sistem BI-
RTGS. Namun apabila terjadi kesalahan, maka sistem akan
mengirimkan hold transaction untuk dilakukan validasi kembali oleh
operator. Selanjutnya operator akan mengirimkan request persetujuan
yang akan disetujui atau tidak disetujui oleh supervisor.
6. Sequence Diagram
Berikut ini merupakan diagram sequence dalam perancangan
aplikasi interface dan integrasi BI-RTGS Gen II. Sequence diagram
yang digambarkan ini dibagi menjadi 4 alur. Diantaranya, alur
sequence diagram untuk transaksi incoming positif, alur sequence

75
diagram untuk transaksi hold incoming, alur sequence diagram untuk
transaksi outgoing positif dan alur sequence diagram untuk transaksi
hold outgoing.
a. Sequence Diagram Transaksi Incoming Positif
Gambar 4.9. alur sequence diagram untuk transaksi incoming positif

76
b. Sequence Diagram Transaksi Hold Incoming
Gambar 4.10. alur sequence diagram untuk transaksi hold incoming

77
c. Sequence Diagram Transaksi Outgoing Positif
gambar 4.11. alur sequence diagram untuk transaksi incoming positif

78
d. Sequence Diagram Transaksi Hold Outgoing
gambar 4.12. alur sequence diagram untuk transaksi hold outgoing

79
4.3.5. Desain Database
Dari hasil wawancara dan observasi maka dapat disimpulkan data-data
yang diperlukan dalam perancangan aplikasi interface dan integrasi BI-
RTGS yang sesuai dengan standar yang diperlukan dalam aplikasi BI-RTGS
Gen II. Berikut ini desain database yang dibangun :
Gambar 4.13. Database Diagram

80
4.3.6. Desain Antarmuka
Dibawah ini merupakan Desain User Interface yang menggambarkan
tampilan sistem yang dirancang. Baik dalam sisi Operator admin maupun
supervisor yang ada pada aplikasi interface dan integrasi BI-RTGS.
Gambar 4.14 Halaman Awal Sistem
Gambar di atas merupakan gambar tampilan awal sistem yang
dibangun. Baik tampilan admin, operator dan supervisor. dimana pengguna
di wajibkan untuk memasukan username dan password untuk masuk ke
halaman selanjutnya
Gambar 4.15 Halaman Home monitoring

81
Gambar di atas merupakan gambar tampilan halaman home
monitoring transaksi, halaman ini akan menjadi halaman operator dan
supervisor dalam memeriksa semua transaksi yang masuk dan keluar dari
sistem dan juga melakukan tindakan jika ada transaksi mengalami kendala
atau flow transaksi tidak berjalan dengan semesti nya.
Fitur monitoring memiliki fungsi sebagai berikut :
1. Melihat detail transaksi incoming (dari BI RTGS ke Core Banking)
secara real-time :
a) Append adalah transaksi yang sudah di selesai dikonversi oleh
interface dan siap dikirim ke core banking.
b) Hold adalah transaksi yang di hold karena validasi interface atau
flow transaksi tidak berjalan dengan semestinya.
c) GFIT(202) adalah transaksi incoming untuk MT202 atau
transaksi dari peserta untuk peserta.
d) Waiting Approval adalah transaksi yang menunggu keputusan
dari supervisor.
e) Converted adalah transaksi yang selesai di konversi ke format
core banking.
f) Request Retur adalah transaksi yang di retur oleh bank lain.
2. Melihat detail transaksi outgoing (dari Core Banking ke BI RTGS)
a) Converted adalah transaksi yang selesai di konversi ke format
BI RTGS.

82
b) Hold transaksi yang di hold karena validasi interface atau flow
transaksi tidak berjalan dengan semestinya.
c) Waiting Approval adalah transaksi yang menunggu keputusan
dari supervisor.
d) Waiting ACK adalah transaksi yang sudah di kirim BI tapi
belum mendapatkan MT196,MT199 dan MT900 merupakan
notifikasi dari BI RTGS.
e) Request Retur adalah transaksi yang meminta bank pengirim
mengembalikan transaksi outgoing yang sudah selesai
sebelumnya.
Gambar 4.16 Halaman Home dashboard
Gambar diatas merupakan gambar tampilan halaman home

83
dashboard yang berisi informasi jumlah transaksi hari ini . dan status
koneksi dari interaface ke BI-RTGS(RTSX) dan interface ke core banking.
Gambar 4.17 Halaman Home monitoring

84
Gambar di atas merupakan halaman detail transaksi untuk melihat
alasan kenapa transaksi ini di hold dan kegiatan operator untuk melakukan
tindakan terhadap transaksi tersebut.
Gambar 4.18 Halaman User Maintenance
Gambar di atas merupakan halaman User Maintenance yang
digunakan oleh user administrator untuk melakukan hal-hal sebagai berikut :
a) Menambah user baru dengan mengisi access id (username),
name (nama user), email address, dan menentukan level user.

85
b) Menentukan global parameter untuk Login Attempts dan
Password Expiry (berlaku untuk semua user).
c) Export data user dalam format .xls.
Gambar 4.19 Halaman Member Maintenance
Gambar di atas merupakan halaman Member maintenance yang
berisikan data peserta member BI-RTGS. diperuntukan user administrator
untuk melakukan hal sebagai berikut :
a) Menambah peserta BI-RTGS baru.
b) Merubah data peserta BI-RTGS.
c) Menghapus data peserta BI-RTGS.

86
Gambar 4.20 Halaman System Configuration
Gambar di atas merupakan halaman yang digunakan oleh user
administrator untuk menyalakan dan mematikan penjadwalan otomatis.
Gambar 4.21 Halaman Account Blacklist

87
administrator untuk merubah, menambah dan menghapus catatan blacklist
di sistem interface yang berguna untuk menyaring semua transaksi yang
masuk melalui interface.
Gambar 4.22 Halaman amount capping

88
Gambar di atas merupakan halaman amount capping yang digunakan
user untuk menentukan maksimum nominal transfer melalui aplikasi
interface. jika ada transaksi dengan nominal melebihi batas maksimum
maka transaksi itu akan terhold untuk validasi manual oleh operator.
Gambar 4.23 Halaman File & Folders - Folders
Gambar 4.24 Halaman File & Folders - FTP

89
administrator untuk melakukan pengaturan letak folder FTP yang akan
digunakan lalu lintas file transaksi antara Core Banking , interface dan BI-
RTGS.
Gambar 4.25 Halaman Report
Gambar di atas merupakan halaman reporting bedasarkan status
transaksi perhari ini yang akan di gunakan oleh operator dan supervisor.

90
Gambar 4.26 Halaman Pencarian Transaksi
Gambar di atas merupakan halaman pencarian transaksi yang sudah pernah
masuk melalui aplikasi interface ini.
4.4. Tahap Implementasi
Dalam tahap implementasi akan menjelaskan mengenai perangkat
yang digunakan, tahap pembuatan sistem, instalasi sistem, pengoperasian
sistem dan pengujian sistem aplikasi interface dan integrasi BI-RTGS Gen
II.

91
4.4.1. Perangkat Yang Digunakan
1. Spesifikasi Perangkat Keras
Berikut ini merupakan beberapa perangkat keras yang digunakan
untuk mendukung implementasi sistem yang dibangun :
No Perangkat Keras Keterangan
1 Server Aplikasi Minimum Ram 1gb dengan storage 500gb
2 Server Database Minimum Ram 1gb dengan storage 500gb
2. Spesifikasi Perangkat Lunak
No Perangkat Lunak Keterangan
1 Apache web server standalone server bisa juga menggunakan
XAMPP
2 MS-SQL Microsoft sql 2008
3 Node.js Berfungsi sebagai sebagai cron job
4 PHP php.5.6

92
4.4.2. Pembuatan Sistem
Pada tahap ini peneliti akan membangun sistem aplikasi interface dan
integrasi BI-RTGS Gen II. Pada tahap ini programmer akan melakukan
coding dengan bahasa pemrograman PHP menggunakan framework
codeigniter. Dalam melakukan tahap coding programmer menggunakan
aplikasi Sublime Text sebagai code editor. Sedangkan dalam pembuatan
database menggunakan Microsoft SQL Server 2008. Programmer juga
menggunakan Node.js sebagai engine scheduler untuk pembuatan event
trigger. Penulisan script program dapat dilihat pada bagian lampiran source
code, dan berikut ini potongan kode pemrograman yang dibuat.
4.4.3. Instalasi Sistem
Sebelum aplikasi digunakan, maka perlu dilakukan beberapa instalasi.
Instalasi perangkat meliputi instalasi web server,node js, database server,
browser dan aplikasi yang telah dibuat. Setelah aplikasi dikonfigurasi maka
aplikasi siap dijalankan dan dioperasikan.
4.4.4. Pengoperasian Sistem
Cara menjalankan aplikasi ini adalah dengan membuka web browser
dalam hal ini penulis menggunakan Google Chrome lalu mengetik alamat
url localhost/interface yang digunakan untuk mengakses aplikasi tersebut.
maka aplikasi tersebut sudah bisa dijalankan hanya saja jam operasional
aplikasi ini menjalankan transaksi dimulai dari jam 07.00 sampai jam 16.00

93
jika di luar jam operasional maka walau aplikasi masih bisa diakses
transaksi tidak akan pernah bisa masuk kedalam flow interface. pada saat
jam operasional akan dimulai maka admin yang bertugas menyalakan flow
transaksi dan pada akhir hari maka admin akan mematikan flow transaksi.
untuk masuk ke dalam aplikasi maka user diwajibkan untuk login
menggunakan username dan password.
4.4.5. Pengujian Sistem
Pada tahap ini merupakan tahap pengujian terhadap sistem yang telah
dibuat, dengan menggunakan metode black-box. Pengujian black-box ini
merupakan pengujian yang menekankan pada fungsionalitas dari sebuah
sistem tanpa harus mengetahui bagaimana struktur di dalam perangkat lunak
tersebut. Sistem akan dikatakan berhasil jika fungsi-fungsi yang ada telah
memenuhi spesifikasi kebutuhan yang telah dibuat sebelumnya.
No Deskripsi Hasil yang diharapkan Sebenarnya
1 Core banking kirim Core banking dapat mengakses FTP -
transaksi ke interface file di Server interface dan ada
dihalaman monitoring
2 BI-RTGS kirim transaksi Interface dapat mengakses FTP file -
ke Interface transaksi di server BI-RTGS

94
3 Interface kirim transaksi Interface dapat meletakan transaksi -
Ke BI-RTGS ke dalam folder FTP yang ada di
server BI-RTGS.
4 Interface kirim transaksi Interface dapat meletakan transaksi -
ke core banking ke dalam folder FTP yang ada di
server Core Banking.
5 Validasi transaksi di Semua transaksi yang masuk ke -
interface interface di kondisikan abnormal
apakah transaksi tersebut menjadi
hold.
6 User login Dapat login sesuai -
username password dan
password tidak dapat dilihat
oleh siapapun
7 User Monitoring User dapat melihat semua alur dan -
jumlah yang masuk ke aplikasi
interface
8 User memperbaiki User dapat melihat detail transaksi -
transaksi Hold terhold dan memperbaiki nya untuk

95
meminta persetujuan untuk
melanjutkan transaksi tersebut
9 User mengeluarkan User dapat melihat detail transaksi -
transaksi dari flow terhold dan menekan button
(Request To Drop) Request To Drop untuk meminta
persetujuan.
10 User meretur User dapat melihat detail transaksi -
transaksi(Request Retur) terhold dan menekan button
Request To Retur untuk meminta
persetujuan.
User maintenance User admin dapat melihat data user -
dan dapat menambah , rubah dan
hapus user
System config User admin dapat mematikan dan -
menjalankan flow transaksi untuk
menjaga jam operational
Member maintenance User admin dapat melihat data -
member dan dapat menambah ,
rubah dan hapus member

96
Account Blacklist User admin dapat melihat data -
Account Blacklist dan dapat
menambah , merubah dan hapus
Account Blacklist
Amount Capping User admin dapat merubah -
maksimum nominal transaksi
File dan Folders User admin dapat merubah -
konfigurasi tata letak folder FTP
dan koneksi.
Reports User dapat melihat dan -
mendowload report transaksi
perhari ini.
Advance Search User dapat mencari transaksi yang -
masuk melalui interface dan
mendownload hasil pencarian.
Tabel 4.3 Pengujian Blackbox

BAB V
HASIL DAN PEMBAHASAN
5.1. Komunikasi dan Cara Messaging
Aplikasi interface dan integrasi BI-RTGS dengan Core Banking ini
dibuat untuk membantu menjembatani antara kedua aplikasi perbankan yang
berhubungan dengan transaksi RTGS. Dari permasalahan yang timbul
karena terdapat pembaruan pada sistem BI-RTGS oleh Bank Indonesia,
maka peneliti akan berfokus pada bagaimana alur integrasi kedua aplikasi
tersebut dengan aplikasi interface dan integrasi BI-RTGS. Aplikasi ini
memiliki koneksi dan cara komunikasi sebagai berikut :
1. Koneksi dari Core Banking dengan Interface menggunakan format
messaging lama BI-RTGS (fix length menggunakan format ketentuan
bank) yang akan menggunakan FTP sebagai media kirim mengirim file.
2. Koneksi dari Interface dengan BI-RTGS menggunakan format
messaging baru (Swift messaging berdasarkan ketentuan BI) yang akan
menggunakan FTP sebagai media kirim mengirim file.
5.1.1 Koneksi dari Interface dengan BI-RTGS server (RTSX).
BI-RTGS yang saat ini sudah berkembang menjadi BI-RTGS Gen II
menggunakan format messaging yang berbeda dari sebelumnya dan sudah
melakukan banyak perubahan dari sistem tersebut, perubahan tersebut
berdampak pada semua bank peserta yang menggunakan RTGS sebagai
98

99
salah satu channel transaksi nya mengharuskan terjadinya penyesuaian
untuk tetap dapat terintegrasi dengan sistem BI-RTGS Gen II.
BI-RTGS Gen II memiliki 2 tipe format messaging untuk digunakan
oleh bank peserta dalam melakukan integrasi dengan sistem ini. 2 tipe
format messaging ini menggunakan Swift messaging dan XML. Untuk
melakukan format Swift messaging BI-RTGS memberikan sebuah file
instalasi untuk di install pada server bank peserta untuk digunakan dalam
melakukan transaksi RTGS.
File instalasi ini berisi file-file aplikasi BI-RTGS Gen II yang terdiri
dari RTSX dan STPG. RTSX adalah sebuah aplikasi tatap muka yang bisa
digunakan oleh operator bank peserta dalam melakukan manual transfer
RTGS ke sistem BI-RTGS. Sedangkan STPG adalah sebuah aplikasi yang
digunakan untuk media komunikasi/integrasi dari sistem aplikasi internal
bank peserta ke sistem BI-RTGS .
STPG ini akan memberikan opsi pilihan untuk bank peserta pilih
dalam penulisan messaging. Bank peserta memilih swift messaging sebagai
cara format messaging mereka. lalu STPG akan membuat 3 folder yaitu
folder error, in dan out. Semua folder itu digunakan untuk keperluan
integrasi, selanjutnya folder error itu akan diisi oleh STPG berupa file swift
messaging jika terjadi suatu masalah di sistem BI-RTGS, folder in adalah
folder yang akan diisi oleh STPG berupa file messaging dengan format
swift messaging yang berupa transaksi masuk atau transaksi incoming dari
bank peserta lain dan juga bisa berupa report transaksi yang tercatat di BI-

100
RTGS, sedangkan folder out adalah folder yang akan diisi oleh interface
berupa file swift messaging yang isinya merupakan transaksi outgoing ke
bank lain atau pun messaging lain seperti permintaan report transaksi bank
peserta per hari ini yang tercatat di BI-RTGS.
Interface menggunakan ke 3 folder ini untuk media komunikasi
dengan BI-RTGS. interface akan mengambil dan meletakan file swift
messaging dengan menggunakan FTP koneksi yang akan dipasang di server
folder STPG itu berada.
5.1.2 Koneksi dari Core Banking dengan Interface.
Core banking yang merupakan sistem yang ada di bank untuk
melakukan pencatatan keuangan seluruh nasabah dan juga sebagai sistem
yang menjadi akar utama semua channel transaksi perbankan masih
menggunakan format lama untuk melakukan transaksi RTGS, dikarenakan
itu maka core banking membutuhkan interface untuk media penjembatan
dengan BI-RTGS yang sudah menggunakan format lama. Core Banking
akan meletakan sebuah file messaging ke sebuah folder yang sudah di
tentukan oleh core banking file messaging ini berisikan transaksi outgoing
yang akan dikirim ke BI-RTGS . disini interface menyediakan sebuah folder
dengan nama OUT_FROM_CORE di server interface ini berada untuk
tempat peletakan file messaging tersebut. Core banking menggunakan FTP
untuk melakukan peletakan file lalu interface akan mengambil file tersebut
untuk di masukan ke dalam database interface serta di konversi menjadi
format messaging swift yang akan dikirim ke folder out yang ada di server

101
STPG. Core banking juga menyediakan sebuah Folder untuk digunakan
interface meletakan file transaksi incoming berupa format messaging lama
yang sudah dikonversi dari format baru.
5.2 Flow Transaksi
Untuk komunikasi dari core banking ke interface dan dari interface ke
BI-RTGS (STPG) flow transaksi yang terjadi di bagi 2 fase yaitu flow
outgoing dan flow incoming. penulis akan membahas lebih detail bagaimana
kedua flow itu berjalan.
5.2.1 Flow Outgoing
Outgoing merupakan transaksi yang akan dikirim dari Core banking
ke BI-RTGS melalui interface yang dimana core banking akan menggunakan
format messaging lama yang akan dikonversi menjadi format baru.
Gambar 5.1. Flow Outgoing
Gambar diatas merupakan gambaran flow transaksi outgoing. dari
Internal System disini kita menyebutnya Core Banking melakukan

102
pengiriman data ke interface dimana interface akan melakukan validasi data
berupa data apa saja yang wajib diisi, transaksi duplikat dan juga nominal
maksimum yang diperbolehkan jika semua validasi tersebut menyatakan tidak
ada masalah(OK) maka interface akan langsung mengirim transaksi itu ke BI-
RTGS(RTSX) jika dari validasi tersebut mendapatkan masalah maka disini
akan ada interaksi dengan user untuk melakukan perbaikan (REPAIR) untuk
meneruskan flow transaksi tersebut atau mengeluarkan transaksi ini dari flow
(DROP).
5.2.2 Flow Incoming
Incoming merupakan transaksi yang akan dikirim dari BI-RTGS ke
Core Banking melalui interface yang dimana format messaging yang
digunakan adalah swift messaging yaitu format baru yang akan dikonversi
oleh interface menjadi format lama.
Gambar 5.2. Flow Incoming

103
Gambar diatas merupakan gambaran flow transaksi incoming. dari
server BI-RTGS mengirim file swift file ke interface lalu interface melakukan
validasi berupa data apa saja yang wajib diisi dan transaksi duplikat jika
semua validasi tersebut menyatakan tidak ada masalah (OK) maka interface
akan langsung mengirim transaksi itu ke Core banking jika dari validasi
tersebut mendapatkan masalah maka disini akan ada interaksi dengan user
untuk melakukan perbaikan (REPAIR) untuk meneruskan flow transaksi
tersebut atau mengeluarkan transaksi ini dari flow (DROP). berikut sample
format messaging yang dihasilkan interface untuk core banking dan juga
format messaging dari RTGS.
5.3. Pembahasan Sistem
Hasil output dari aplikasi interface dan integrasi BI RTGS ini dapat
dilihat dari dua transaksi yang berjalan pada aplikasi ini. Kedua transaksi ini
terdiri dari transaksi incoming dan outgoing. Saat transaksi incoming
maupun outgoing masuk, maka aplikasi interface ini akan melakukan
validasi secara otomatis. Validasi ini merupakan proses convert antara
sistem BI-RTGS yang menggunakan format messaging Swift menjadi
format fixed length yang dimiliki oleh sistem core banking.
Gambar 5.3. Format Fixed Length Core Banking

104
Gambar 5.4. Format Swift BI-RTGS
Selanjutnya, ketika transaksi masuk, maka operator akan melakukan
croscek terlebih dahulu apakah data yang ada sudah benar, atau perlu ada
permintaan request kepada supervisor terlebih dahulu.
Gambar 5.5. Halaman Utama pada operator

105
Gambar 5.6. Transaksi Masuk pada Menu Operator
Pada halaman transaksi masuk ini, operator dapat melihat detail
transaction yang tersedia pada transaction list.
Gambar 5.7. Detail Transaction Core Banking

106
Gambar 5.8. Detail Transaction Swift Messaging
Hasil proses konversi pada sistem aplikasi ini dapat terlihat pada
menu detail transaction ini, pada gambar 5.7 dan gambar 5.8 dapat terlihat
pesan diterima dalam bentuk format messaging swift lalu dapat dibaca
dalam format core banking.
Selanjutnya, apabila dalam transaksi tersebut terdapat perubahan
data ataupun permintaan retur, maka operator dapat mengirimkan request
untuk di cek dan disetujui kembali oleh supervisor. Request yang masuk
akan ada dalam menu waiting approval yang akan terlihat oleh supervisor.

107
Gambar 5.9. Permintaan Request Oleh Operator
Gambar 5.9. Waiting Approval pada User Operator

108
Selanjutnya pada user Operator akan menerima request waiting
approval yang dikirimkan oleh operator, maka supervisor dapat membuka
transaksi tersebut dan memilih untuk menerima ataupun menolak request
tersebut.
Gambar 5.10 waiting approval supervisor
Gambar 5.11. Disaprove dan Approve Supervisor

BAB VI
PENUTUP
6.1. Kesimpulan
Berdasarkan hasil dan pembahasan untuk menjawab rumusan masalah
yang ada di dalam penelitian ini, maka dapat ditarik beberapa kesimpulan
sebagai berikut:
1. Aplikasi Interface sebagai penghubung antara sistem BI-RTGS dengan
core banking bank peserta dapat terkoneksi secara real-time dengan
menggunakan teknologi file transfer protocol (FTP).
2. Dari hasil uji coba lapangan, yaitu Bank DKI sebagai pemilik project
bahwa sistem ini mampu berjalan dengan baik dan dapat diterapkan.
Sehingga bank DKI tidak perlu lagi untuk melakukan perubahan pada
sistem core banking.
3. Konversi file antara format baru BI-RTGS yaitu format Swift dengan
format yang ada pada core banking dapat diterjemahkan dengan baik,
sehingga tidak mengganggu jalannya transaksi RTGS pada Bank DKI.
4. Pengadaan Aplikasi ini sangat membantu karena apabila bank peserta
harus merubah sistem sesuai dengan format BI-RTGS maka
membutuhkan biaya besar dan waktu yang cukup lama, sedangkan
transaksi RTGS akan selalu dibutuhkan dan perlu ketersediaan yang
cepat.
109

110
6.2. Saran
Penulis menyadari bahwa penelitian masih jauh dari kata sempurna,
Untuk pengembangan lebih lanjut maka penulis memberikan saran agar
aplikasi ini lebih bermanfaat lagi dan lebih baik lagi:
1. Diharapkan penelitian selanjutnya dapat menjabarkan dengan lengkap apa
saja fitur yang tersedia dalam format Swift yang telah digunakan dalam
standar perbankan Internasional.

111
DAFTAR PUSTAKA
Biro Pengembangan Sistem Pembayaran Nasional (2006), Sistem Bank Indonesia

Real Time Gross Settlement (BI-RTGS).
Rizkyana, Muhammad (2014) Rancangan Arsitektur Aplikasi Pengumpulan

Tugas Dengan Push Notification Real-Time Menggunakan Node.js
Cahyanti, Nila (2018), Prosedur Pelaksanaan Sistem Real Time Gross Settlement
(RTGS) Pada Bank Syariah Mandiri KCP Godean Yogyakarta.
Putri, Nadia Recha (2018) Pengaturan Penyelenggara Sistem Transfer Dana

Perbankan Dalam Kegitaran Transfer Dana Menurut UUD Nomor 3
Tahun 2011
Wandhofer, Ruth, (2018), The Future Of Correspondent Banking Cross Border

Payments.
Kusumaningrum, Nadila, Salsabil, (2018) Mekanisme Transaksi Real Time Gross

Settlement. (RTGS) Pada PT. Bank Tabungan Negara (Persero) Kantor
Cabang Pembantu Syariah Catur Yogyakarta.
Kendall, K. &. (2010). System Analysis and Design Seventh Edition. Prentice
Hall.
Nizamu, Taufik (2016) Analisis Return On Investment Penerapan Sistem

Informasi Core Banking Keuangan Syari’ah
Fugal, Adam (2018) A Proposal for a decentralized liquidity savings mechanism

with side payments.
Sekundera, P, L (2006) Analisis Penerimaan Pengguna Akhir Dengan

Menggunakan Technology Acceptance Model dan End User Computing
Satisfaction Terhadap Penerapan Sistem Core Banking Pada Bank AB.
Untoro (2014) Bank Indonesia Working Paper : Kajian Penggunaan Instrument

Sistem Pembayaran Sebagai Leading Indicator Stabilitas Sistem
Keuangan.
Kohli, Manu dan Edgardo, Suarez (2016), Centralized Solution to Securely
Transfer Payment Information Electronically to Banks for Multiple ERP
Systems. International Journal of Computer and Information Technology.
Nazir, Moh. (2005) Metode Penelitian. Jakarta : Ghalia Indonesia.

112
Jogianto (2008) Analisis dan Desain Sistem Informasi : Pendekatan Terstruktur
Teori dan Praktek Aplikasi Bisnis. Yogyakarta : Andi.
Jnana Ranjan Dhir, (2015) Impact of Information Technologi (IT) Applications on
Bank Industry. International Journal of Computer and Information
Technology.

113

Skripsi - Bethari Zattira 1112091000128

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Skripsi - Bethari Zattira 1112091000128

Diunggah oleh

Hak Cipta:

Format Tersedia

RANCANGAN APLIKASI INTERFACE DAN INTEGRASI BI-

RTGS GEN II DENGAN SISTEM BANK PESERTA BI-RTGS

(Studi Kasus : PT. Visigo)

PROGRAM STUDI TEKNOLOGI INFORMASI

FAKULTAS SAINS DAN TEKNOLOGI

UNIVERSITAS ISLAM NEGERI SYARIF HIDAYATULLAH

UIN SYARIF HIDAYATULLAH JAKARTA

UIN SYARIF HIDAYATULLAH JAKARTA

Dengan ini saya menyatakan bahwa:

salah satu persyaratan memperoleh gelar Strata 1 di UIN Syarif Hidayatullah

dengan ketentuan yang berlaku di UIN Syarif Hidayatullah Jakarta.

Jakarta, Mei 2019

UIN SYARIF HIDAYATULLAH JAKARTA

pengikutnya hingga akhir zaman.

Skripsi penulis yang berjudul “Rancangan Aplikasi Interface dan

Integrasi BI-RTGS Dengan Sistem Bank Peserta BI-RTGS ” disusun untuk

Program Studi Teknik Informatika, Universitas Islam Negeri Syarif Hidayatullah

Suatu kebanggan tersendiri bagi penulis apabila skripsi ini dapat

bermanfaat terutama bagi pihak-pihak yang membutuhkannya. Pada kesempatan

terlaksana dengan baik. Secara khusus penulis mengucapkan terimakasih kepada:

1. Ibu Prof.Dr.Lily Surraya Eka Putri,M.Env.Stud, Selaku Dekan Fakultas Sains

Feri Fahrianto, Sc selaku Sekretaris Jurusan Program Studi Teknik

Informatika, yang selalu memberikan motivasi dan arahan kepada penulis.

UIN SYARIF HIDAYATULLAH JAKARTA

bimbingan kepada penulis.

4. Seluruh Dosen Program Studi Teknik Informatika, Fakultas Sains dan

Teknologi. Yang telah banyak memberikan bimbingan dan pengarahan

kepada penulis selama menjalankan aktifitas perkuliahan.

support tak terbatas dan memperjuangkan apapun agar peneliti dapat

menyelesaikan penelitian skripsi ini.

dukungan dan doa yang tidak pernah berhenti.

saya lainnya yang telah memberikan motivasi agar penulis menyelesaikan

studi S1 sesegera mungkin.

untuk disebutkan satu per satu.

11. Terimakasih kepada rekan-rekan seperjuangan di UIN Syarif Hidayatullah

Jakarta, yang telah memberikan dukungan dan semangat serta saran-saran

yang berguna hingga akhir penulisan skripsi ini.

UIN SYARIF HIDAYATULLAH JAKARTA

memberikan berkah dan karunia-Nya serta membalas kebaikan mereka.

UIN SYARIF HIDAYATULLAH JAKARTA

Untuk meningkatkan keamanan lalu lintas transaksi penyaluran dana, Bank

Kata Kunci : Format Messaging, Swift Code, PHP, Node.js

UIN SYARIF HIDAYATULLAH JAKARTA

LEMBAR PESETUJUAN PEMBIMBING ....................................................i

2.1. Definisi Pengembangan...................................................................11

UIN SYARIF HIDAYATULLAH JAKARTA

UIN SYARIF HIDAYATULLAH JAKARTA

5.1 Komunikasi dan Cara Messaging .....................................................98

UIN SYARIF HIDAYATULLAH JAKARTA

Gambar 2.1. Alur pembayaran lintas negara..................................................16

UIN SYARIF HIDAYATULLAH JAKARTA

UIN SYARIF HIDAYATULLAH JAKARTA

Tabel 2.1 Klasifikasi Message Type .........................................................18

UIN SYARIF HIDAYATULLAH JAKARTA

UIN SYARIF HIDAYATULLAH JAKARTA

1.1. Latar Belakang

lain dipengaruhi oleh perkembangan jasa keuangan dan perbankan global

serta munculnya beragam produk perbankan dan layanan jasa perbankan

yang diperbarui. Terlebih lagi dengan banyaknya kebutuhan masyarakat

khususnya pelaku bisnis yang membutuhkan layanan penyaluran dana

Untuk meningkatkan mitigasi resiko yang terjadi pada lalu lintas

yang menaungi semua bank yang beroperasi di indonesia menerbitkan

sistem sentralisasi lalu lintas transaksi yang dinamakan BI-RTGS (Real

Time Gross Settlement) untuk memonitoring dan memfasilitasi semua