Ringkasan: MT103 terdiri dari header jaringan, basic
header, dan deretan field bernomor (:20:, :23B:, :32A:, :50a:, :59a:,
:70:, :71A: dst). Memahami fungsi tiap field = bisa membaca dokumen
“MT103 copy” yang masuk ke inbox Anda — dan tahu bagaimana menangkap
yang palsu.
1. Struktur Besar Sebuah
MT103
{1: Basic Header} → identitas pengirim + tipe sesi
{2: Application Header} → MT103 + prioritas + bank penerima
{3: User Header} → layanan khusus (mis. :121: UETR, STP)
{4: Text Body} → field-field bernomor (inti instruksi)
{5: Trailer} → tanda akhir pesan (MAC/checksum)
Yang biasa dilampirkan orang sebagai “bukti transfer” adalah
cetak dari text body — sering plus user header. Karena
tampilannya teknis, dokumen palsu mudah terlihat “meyakinkan” bagi orang
awam.
2. Field-Field Kunci (Text
Body)
:20: Sender’s
Reference — nomor referensi pengirim
ID internal transaksi versi bank pengirim. Bebas format (alfanumerik,
max 16 karakter). Bukan penanda unik global — itulah gunanya UETR.
:23B: Bank Operation Code
— kode operasi
CRED— credit transfer biasa (99% kasus).CRTS— credit transfer dengan aspek settlement
tertentu.
:23E:
Instruction Code — instruksi tambahan (opsional, berulang)
Contoh: HOLD (tahan untuk ambil), CHQB
(bayar via cek), PHOB/TELB (telepon
beneficiary), INTC (transfer antar perusahaan sekawan).
Daftar lengkap ada di SWIFT Standards.
:26T:
Transaction Type Code — jenis transaksi (opsional)
Kode 3 huruf untuk klasifikasi (mis. perdagangan barang, gaji,
dividen) — membantu compliance klasifikasi purpose.
:32A:
Value Date / Currency / Interbank Settled Amount — tanggal nilai,
mata uang, jumlah settlement
Format: YYMMDD + CCY + amount
dengan koma sebagai desimal (standar SWIFT):
:32A:260828USD1.500.000,00
= 28 Agustus 2026, USD 1.500.000,00. Field ini wajib
dan menjadi acuan tanggal nilai antarbank.
:33B:
Currency / Instructed Amount — mata uang & jumlah yang
diinstruksikan
Jumlah versi nasabah pengirim sebelum konversi. Bila beda mata uang
dengan :32A:, muncul field :36: (Exchange Rate).
:50a: Ordering
Customer — nasabah pengirim (wajib)
Nama + rekening pengirim (varian :50: atau :50F: dengan alamat
terstruktur). Inilah yang dibaca screening sanksi di bank-bank
rantai.
:52a:
Ordering Institution — bank pengirim asal (opsional)
Relevan bila pengirim sebenarnya lewat bank lain di hulu.
:53a: /
:54a: / :55a: — correspondent pengirim / penerima / ketiga
Rekening interbank yang dipakai untuk settlement (NOSTRO/VOSTRO).
Kosong = bank-bank punya relasi langsung.
:56a: Intermediary
Institution — bank perantara
Bank di tengah rantai (mis. bank kustodian penerima di negara
lain).
:57a:
Account With Institution — bank pemilik rekening penerima
Penting bila bank yang menerima pesan bukan bank tempat rekening
penerima berada.
:59a:
Beneficiary Customer — nasabah penerima (wajib)
Nama + nomor rekening/IBAN penerima. Kesalahan 1 karakter di sini =
dana berhenti di jalur investigasi, bukan sampai tujuan.
:70:
Remittance Information — keterangan pembayaran
4 baris × 35 karakter. Berita/keterangan dari pengirim (“Pembayaran
invoice 1234”). Bukan tempat instruksi operasional
bank.
:71A: Details of
Charges — pembagian biaya (wajib)
OUR— semua biaya ditanggung pengirim.BEN— semua biaya ditanggung penerima (dipotong dari
dana).SHA— biaya dibagi (masing-masing bank potong untuk
nasabahnya sendiri).
:71F: /
:71G: Sender’s / Receiver’s Charges — rincian biaya
Kumulatif biaya yang sudah dipotong bank-bank di rantai.
:72:
Sender to Receiver Information — info bank-ke-bank
Kode internal antar bank (mis. instruksi reconcile, agreement
referensi). Bukan untuk dikonsumsi nasabah.
3. User Header — :121: UETR
{121:8f4a3c1e-9b2d-4c7a-a1b2-3d4e5f6a7b8c}
UETR (Unique End-to-End Transaction
Reference) — UUID 36 karakter yang menjadi “KTP” transaksi di
seluruh rantai gpi. Wajib untuk pembayaran SWIFT gpi sejak Standards
Release 2018. Lewat UETR inilah bank dapat melacak posisi dana via gpi
Tracker. Format penyajian UETR yang salah di dokumen “copy” adalah red
flag klasik.
4. Contoh Struktur
(ILUSTRASI SINTETIK)
⚠️ Contoh di bawah adalah dokumen buatan untuk
edukasi — seluruh nama, referensi, dan angka fiktif. Jangan
perlakukan sebagai format resmi untuk menyusun dokumen sungguhan.
:20:KRMDMO260828001
:23B:CRED
:32A:260828USD1.500.000,00
:33B:IDR23.400.000.000,00
:36:15600
:50K:/1234567890
PT KOPI NUSANTARA SEJAHTERA
JL. JEND. SUDIRMAN KAV. 52
JAKARTA
:52A:BNIAIDJAXXX
:57A:CHASUS33XXX
:59:/987654321
PT KOPI IMPORT LLC
350 FIFTH AVENUE
NEW YORK
:70:/INV/2026/0891
PAYMENT FOR GREEN COFFEE BEANS
:71A:SHA
Cara membacanya: bank BNIAIDJAXXX menginstruksikan CHASUS33XXX
mengkredit USD 1,5 juta untuk PT KOPI IMPORT LLC (rekening 987654321)
atas nama PT KOPI NUSANTARA SEJAHTERA, untuk invoice 2026/0891, biaya
dibagi SHA, tanggal nilai 28 Agustus 2026.
5. Red Flag Format pada
“MT103 Copy” Palsu
| Red flag | Kenapa mencurigakan |
|---|---|
| :32A: pakai titik desimal, bukan koma | Standar SWIFT memakai koma |
:32A: tanggal formatDDMMYYYY/YYYY-MM-DD |
Standar adalah YYMMDD |
| UETR bukan UUID 36 karakter / hilang di dokumen gpi | Struktur baku field :121: |
| Jumlah pakai “USD 1,5M” / singkatan | Jumlah harus eksplisit, tanpa singkatan |
| Ada “conditional hold”, “one-way”, “IPID”, “IPIP” | Tidak ada field/konsep itu dalam standar MT103 |
| BIC penerima tidak cocok dengan bank di :57a:/:59a: | Bisa dicek publik di direktori BIC |
| Logo bank pengirim & layout asing dibanding sampel resmi | Dokumen asli keluar dari sistem core banking, bukan editor |
Verifikasi mendalam: artikel
08 — Cara Verifikasi MT103.
6. Sumber
- SWIFT Standards — spesifikasi field MT kategori 1 — https://www.swift.com/standards
(diakses 28 Agu 2026) - SWIFT gpi — UETR & aturan penggunaan — https://www.swift.com/our-solutions/swift-gpi
(diakses 28 Agu 2026) - ISO 9362 (BIC) — kode identifikasi bank — https://www.iso.org (diakses 28 Agu
2026) - ISO 20022 RA — penerus pesan (pacs.008) — https://www.iso20022.org (diakses 28
Agu 2026)








Tinggalkan Balasan