> For the complete documentation index, see [llms.txt](https://krimkopi.gitbook.io/krimkopi-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://krimkopi.gitbook.io/krimkopi-docs/articles/03-anatomi-mt103.md). # Anatomi Pesan MT103 — Bedah Field-per-Field > **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. **Kategori:** Teknis · **Level:** Menengah · **Estimasi baca:** 10 menit *** ## 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 format `DDMMYYYY`/`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](/krimkopi-docs/articles/08-verifikasi-mt103.md). ## 6. Sumber 1. SWIFT Standards — spesifikasi field MT kategori 1 — (diakses 28 Agu 2026) 2. SWIFT gpi — UETR & aturan penggunaan — (diakses 28 Agu 2026) 3. ISO 9362 (BIC) — kode identifikasi bank — (diakses 28 Agu 2026) 4. ISO 20022 RA — penerus pesan (pacs.008) — (diakses 28 Agu 2026) *** *Artikel ini bagian dari knowledge base* [*krimkopi.my.id*](https://krimkopi.my.id)*. Berikutnya:* [*MT103 vs MT202 vs pacs.008 →*](/krimkopi-docs/articles/04-mt103-vs-mt202-vs-pacs008.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://krimkopi.gitbook.io/krimkopi-docs/articles/03-anatomi-mt103.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.