Ikhtisar
FATF Travel Rule (Rekomendasi 16), yang diterapkan di UE sebagai Transfer of Funds Regulation, mewajibkan Penyedia Layanan Aset Virtual (VASP) pengirim (VASP pengirim) untuk mengumpulkan dan mengirimkan informasi pengirim dan penerima kepada VASP penerima (VASP penerima) sebelum transfer aset virtual diselesaikan. Berbeda dengan sebagian besar yurisdiksi, EU TFR berlaku tanpa jumlah minimum: setiap transfer kripto termasuk dalam cakupan, bukan hanya transfer di atas ambang pelaporan. Produk Travel Rule dari Didit adalah pertukaran terkelola, bukan sekadar kolom data:- Anda mengirimkan transfer dengan
transaction_category: "travelRule". - Didit mencoba jalur sesuai urutan prioritas untuk menjangkau VASP pihak lawan, menjalankan pertukaran melalui jalur pertama yang berhasil menjangkaunya, dan, jika pihak lain mengembalikan nama penerima, mencocokkannya dengan nama yang Anda kirim.
- Anda hanya boleh menyiarkan transfer di on-chain setelah pertukaran mencapai
COMPLETED. - Anda kemudian melaporkan hash transaksi on-chain kembali ke Didit untuk menutup pertukaran dengan status
FINISHED.
GTR, TRUST, VERIFYVASP, SYGNA) memerlukan keanggotaan jaringan di sisi pengirim, dan saat ini keanggotaan tersebut harus milik Anda sendiri.
Hubungkan kredensial keanggotaan Anda di Marketplace konsol (kategori Travel Rule networks), dan transfer Anda akan berjalan di bawah identitas jaringan Anda sendiri.
Didit tidak memiliki keanggotaan platform untuk keempat jaringan saat ini, dan sedang melakukan onboarding sebagai penyedia di jaringan tersebut.
Sampai onboarding itu selesai, platform_available bernilai false untuk keempatnya, mode pengaturan didit (perutean melalui keanggotaan platform Didit) tidak tersedia untuk jaringan mana pun, dan disabled_networks tidak memiliki apa pun untuk dinonaktifkan.
Keanggotaan yang Anda hubungkan sendiri selalu didahulukan dibanding keanggotaan platform.
Tidak ada keanggotaan jaringan yang disertakan secara default, termasuk GTR.
Mengaktifkan Travel Rule tidak mengaktifkan GTR, TRUST, VerifyVASP, atau Sygna.
Periksa Get Travel Rule Settings untuk mode networks efektif aplikasi Anda, dan Travel Rule networks untuk jangkauan setiap jaringan saat ini.
Jika keempatnya melaporkan unavailable, tidak ada yang dapat merutekan pertukaran: hubungkan keanggotaan Anda sendiri di Marketplace, atau gunakan pihak lawan INTERNAL, TRP, atau EMAIL yang dapat dijangkau.
Saat Anda menyimpan keanggotaan, kode pesertanya harus milik Anda sendiri: permintaan penyimpanan menghasilkan respons 400 jika kodenya adalah kode Didit sendiri di jaringan tersebut, atau kode yang sudah dimiliki keanggotaan aplikasi lain.
Keanggotaan GTR memerlukan kunci privat ed25519 (base64), yang kunci publiknya didaftarkan di portal GTR: kunci ini mengenkripsi data pribadi yang Anda kirim dan mendekripsi data yang Anda terima.
Keanggotaan VerifyVASP mengarah ke Enclave VerifyVASP milik Anda sendiri: URL-nya adalah URL Enclave Anda, dan token-nya adalah token yang disajikan Enclave Anda kepada Didit.
Bahkan dengan keanggotaan Anda sendiri, jalur jaringan hanya merutekan transfer jika beneficiary_data-nya memuat id pihak lawan di jaringan tersebut (counterparty_gtr_vasp_code, counterparty_trust_membership_id, counterparty_verifyvasp_id, atau counterparty_sygna_vasp_code), atau entri direktori pihak lawan mencantumkannya di jaringan tersebut (lihat Routes).
platform_available melaporkan apakah keanggotaan platform telah dikonfigurasi, bukan pemeriksaan status jaringan secara langsung. Demikian pula, connected berarti kredensial keanggotaan Anda telah disimpan dan lolos validasi lokal; pertukaran langsung pertama akan memverifikasinya terhadap jaringan. Mode didit atau own tidak menjamin kemampuan menjangkau pihak lawan maupun keberhasilan pengiriman.
Dengan keanggotaan Anda sendiri, Didit membaca jawaban pihak lawan melalui GTR, VERIFYVASP dan SYGNA dari respons jaringan atau dengan melakukan polling ke jaringan setiap 5 menit, yang kemudian menyelesaikan atau menolak transfer.
TRUST hanya untuk pengiriman: transfer yang dikirim melalui jalur ini tetap berada di AWAITING_COUNTERPARTY hingga confirmation_timeout_hours berlalu, lalu berpindah ke EXPIRED dan timeout_outcome Anda berlaku.
Penerimaan transfer yang dikirim VASP lain kepada Anda melalui jaringan belum diaktifkan, dan belum ada pertukaran melalui jaringan yang telah diselesaikan dengan jaringan produksi: lihat Jaringan Travel Rule.
Jaringan lain - CODE (aliansi Korea), TRISA, Notabene, dan Veriscope - tercantum di Marketplace konsol sebagai kartu permintaan akses.
Didit belum memiliki integrasi dengan jaringan tersebut, sehingga belum ada transfer yang dapat dirutekan melalui jaringan tersebut saat ini.
Ketika ketujuh jalur tidak dapat menentukan pihak lawan, Didit menjalankan satu langkah resolusi lagi sebelum menyerah: atribusi analitik blockchain.
Dompet tujuan dicocokkan dengan data analitik blockchain; ketika dompet tersebut milik bursa atau kustodian yang dikenal, Didit mencatat VASP hasil atribusi pada transfer, menambahkannya ke direktori, dan menjalankan ulang jalur sekali dengan nama baru.
Lihat Atribusi analitik blockchain untuk perilaku lengkap dan harganya.
Transfer yang tujuannya dideklarasikan sebagai dompet swakelola melewati ketujuh jalur - tidak ada VASP pihak lawan untuk diajak bertukar informasi - dan langsung menuju pembuktian kepemilikan dompet pengguna akhir.
/v3/ yang dijelaskan di halaman ini.Apa yang dijalankan saat Anda mengirim transfer
Pemeriksaan berjalan di dalam satu panggilanPOST /v3/transactions/. Saat Anda menerima respons, skrining sudah dijalankan, transfer sudah disimpan, dan aturan sudah dievaluasi.
Pertukaran data sendiri dimulai setelah respons: Didit memilih rail dan menghubungi pihak lawan di luar permintaan Anda, sehingga tidak ada jaringan atau pihak lawan yang dapat memperlambat atau menggagalkan pembuatan transaksi.
Setiap perubahan status setelah itu dikirim sebagai webhook travel_rule.status.updated yang menyebutkan rail, dan objek transfer yang dikembalikan endpoint transfer Travel Rule memuat field delivery yang menunjukkan apakah pesan berhasil terkirim.
Tidak ada pipeline yang perlu di-polling. Bagian yang asinkron adalah pertukaran data, jawaban pihak lawan, dan tindakan pengguna akhir.
Langkah demi langkah:
- Validasi dan pengikatan subjek. Payload divalidasi.
transaction_idyang sudah dipakai di aplikasi Anda akan ditolak dengan400, dan jika dua permintaan dengan id yang sama berjalan bersamaan, salah satunya menerima409.subjectditautkan ke profil pengguna atau bisnis Anda melaluivendor_data, sehingga transfer muncul di profil tersebut untuk pemantauan.vendor_datasubjek atau pihak lawan yang masuk daftar blokir ditolak dengan400, dan tidak ada transaksi yang dibuat. Dompet, rekening bank, IP, dan perangkat yang masuk daftar blokir diperiksa pada langkah 6 dan menolak transaksi di sana, setelah routing dijalankan. - Pengayaan perangkat dan jaringan. IP pihak-pihak diperkaya dengan data geografis, dan konteks perangkat apa pun (otomatis saat pengiriman melalui SDK) dinormalisasi ke dalam graf perangkat. Ini adalah graf yang sama dengan yang diisi sesi KYC, sehingga “terkait berdasarkan perangkat” berlaku lintas onboarding dan transaksi.
- Skrining kripto. Untuk transfer kripto dengan pemantauan aktif, dompet terkait (atau hash on-chain) diskrining terhadap analitik blockchain sebelum ada yang dipertukarkan: paparan sanksi, kedekatan dengan mixer, dana hasil curian. Lihat Skrining kripto & dompet.
- Transfer Travel Rule. Mesin pertukaran memeriksa ambang batas dan menghormati deklarasi dompet swakelola, lalu menyimpan transfer:
NOT_APPLICABLEdi bawah ambang batas Anda,UNCONFIRMED_OWNERSHIPuntuk dompet swakelola yang dideklarasikan,COMPLETEDketika dompet lawan adalah dompet terverifikasi milik Anda sendiri, danAWAITING_COUNTERPARTYselain itu, dengan rail yang masih kosong. Setiap perubahan status memasukkan eventtravel_rule.status.updatedke antrean, dan Didit mengirimkannya setelahtransaction.createdmilik transaksi (langkah 7). - Penerbitan widget kepemilikan dompet. Jika transfer membutuhkan bukti kontrol dari pengguna akhir dan
auto_wallet_verificationaktif, sesi widget kepemilikan dompet diterbitkan dan dikembalikan dalamaction_required. - Evaluasi aturan. Setiap aturan aktif dijalankan. Bundel EU TFR bereaksi terhadap status transfer yang ditetapkan pada langkah 4, aturan kustom Anda melihat keluaran skrining dari langkah 3, dan sebuah aturan dapat menahan transaksi (
IN_REVIEW), menolaknya, atau meminta verifikasi tingkat lanjut (AWAITING_USER). - Penagihan dan notifikasi. Transaksi keluar ditagihkan dalam satu baris: baris Travel Rule ketika transaksi memulai pertukaran data, dan Transaction Screening selain itu. Transfer masuk tidak dikenakan biaya apa pun, dan aplikasi sandbox tidak pernah ditagih.
Respons dikembalikan, dan event
transaction.createddikirim ke tujuan webhook Anda, diikuti eventtravel_rule.status.updateddari langkah 4. - Routing, setelah respons. Didit menelusuri tujuh rail sesuai urutan prioritas. Jika tidak ada yang berhasil, atribusi analitik blockchain mengidentifikasi pihak lawan dan rail dijalankan ulang sekali. Rail pertama yang dapat dijangkau membawa pertukaran data: transfer tetap
AWAITING_COUNTERPARTYdi rail tersebut selama pihak lawan belum menjawab, langsung diselesaikan ketika pihak lawanINTERNALditemukan (COMPLETEDatauCOUNTERPARTY_MISMATCHED_DATA), atau menjadiCOUNTERPARTY_VASP_NOT_FOUNDketika tidak ada rail yang menjangkau pihak lawan. Setiap perubahan memicutravel_rule.status.updated, dan aturan Anda dijalankan ulang setiap kali status atau rail berubah. Transfer yang masih berstatusCOUNTERPARTY_VASP_NOT_FOUNDsetelah routing menerima sesi widget kepemilikan dompetnya pada titik itu (jikaauto_wallet_verificationaktif). Bacalah dariaction_requiredtransaksi dengan Ambil transaksi.
Bagaimana setiap langkah memenuhi kewajiban Anda
transaction.created atau transaction.status.updated. Transaksi sandbox tetap APPROVED kecuali timeout_outcome Anda diterapkan pada transfer Travel Rule yang kedaluwarsa, dan tidak ada yang ditagih.
Mesin pertukaran Travel Rule itu sendiri berjalan di aplikasi sandbox ketika Travel Rule diaktifkan, hanya melawan satu pihak lawan: setiap pertukaran keluar diarahkan ke Didit Test VASP di rail TEST_VASP, yang menjawab di dalam Didit dengan skenario yang Anda pilih, sehingga transfer dapat selesai, ditolak, tidak cocok, tidak dapat dijangkau, kedaluwarsa, atau menunggu kepemilikan dompet.
Tidak ada pesan kepatuhan yang pernah sampai ke VASP pihak lawan yang sungguhan, dan webhook travel_rule.status.updated dikirim dengan environment: sandbox.
Untuk transfer masuk, VASP pengujian dapat mengirimkan transfer kepada Anda (Picu Transfer Masuk Test VASP), dan registrasi (POST /v3/travel-rule/inbound/) diselesaikan terhadap buku alamat dompet Anda seperti pada aplikasi produksi: ON_HOLD, UNCONFIRMED_OWNERSHIP, COUNTERPARTY_MISMATCHED_DATA, atau COMPLETED lalu FINISHED.
Lihat Menguji Travel Rule di sandbox.Siklus hidup
Setiap transfer memilikistatus yang dipilih dari 13 nilai. Pertukaran dimulai dari AWAITING_COUNTERPARTY dalam kondisi normal, dari NOT_APPLICABLE ketika jumlahnya di bawah threshold_amount Anda atau permintaan pembayaran Lightning tidak mencantumkan penerima (lihat Lightning), atau dari UNCONFIRMED_OWNERSHIP ketika tujuan telah dinyatakan sebagai dompet swakelola. Pertukaran berakhir di salah satu status akhir: FINISHED, CANCELLED, atau EXPIRED.
Transfer menjalankan mesin status sendiri, terpisah dari status tinjauan transaksi yang mendasarinya. Status pertukaran tidak pernah mengubah status transaksi dengan sendirinya, dengan satu pengecualian: kedaluwarsa menerapkan timeout_outcome yang Anda konfigurasi (atau kebijakan sunrise atau non-responsif jika berlaku). Sebagai gantinya, aturan Anda dijalankan ulang pada setiap transisi, sehingga aturan EU TFR atau aturan apa pun yang menggunakan travel_rule_status dapat memindahkan transaksi, misalnya ke IN_REVIEW. Transfer yang memerlukan bukti kontrol dompet dari pengguna akhir menambahkan blok action_required ke transaksi, tetapi status-nya tetap seperti yang ditetapkan aturan Anda. Baca status pertukaran dari travel_rule.status, dan baca keputusan izinkan / tahan / tolak dari status transaksi itu sendiri.
Setiap transisi (dan setiap status yang dilaporkan secara pasif) juga dicerminkan ke nilai kustom transaksi agar aturan dapat merujuknya: custom_values.travel_rule_status (status kanonis), custom_values.travel_rule_rail (jalur yang membawa pertukaran, kosong hingga satu jalur dipilih), dan custom_values.travel_rule_regime (diturunkan dari jurisdiction di pengaturan Anda: SG → singapore, GB → uk, dan kode anggota EU atau EEA apa pun seperti DE atau FR → eu; kode yang tidak dipetakan ditetapkan dalam huruf kecil, misalnya US → us. props.travel_rule_regime yang Anda kirim sendiri selalu didahulukan daripada nilai yang diturunkan).
CANCELLED juga dapat dicapai dari setiap status non-terminal dengan action: "cancel"):
Pengiriman dan coba lagi
Didit mengirim setiap pesan yang wajib dikirim oleh sebuah transfer di luar permintaan yang memicunya, dan mencoba lagi hingga pihak lawan menerimanya. Objek transfer yang dikembalikan oleh Selesaikan, batalkan, atau kirim ulang, Konfirmasi kepemilikan dan pendaftaran sunrise memuat pesan terbaru didelivery, begitu pula objek travel_rule yang tertanam pada transaksi. Nilainya null jika transfer tidak pernah wajib mengirim pesan.
408, 429 atau 5xx) dicoba ulang setelah 30 detik, 2 menit, 10 menit, 30 menit, dan 1 jam.
Ketika pesan pertama gagal permanen, yaitu jaringan menolaknya atau percobaan keenam juga gagal, transfer berpindah ke COUNTERPARTY_VASP_NOT_REACHABLE dengan last_error di dalam timeline, dan Anda dapat mencoba lagi dengan action: "resend".
Pesan lain yang gagal permanen dicatat di timeline.
delivery tidak pernah menggantikan status transfer: baca hasil pertukaran dari status, dan gunakan delivery untuk melihat mengapa transfer masih menunggu.
Nilai status lama
Jika Anda sudah mengirimtravel_rule_details.status sebelum rilis ini, nilai-nilai tersebut tetap berfungsi dan dipetakan secara otomatis.
Varian camelCase dari status apa pun (misalnya counterpartyVaspNotFound) juga diterima, baik saat pengiriman data maupun dalam nilai kondisi aturan, dan dinormalisasi ke bentuk kanonis:
Pengaturan
Konfigurasi profil VASP dan kebijakan negosiasi Anda sekali per aplikasi denganGET/PUT /v3/travel-rule/settings/.
PUT adalah pembaruan parsial - kirim hanya kolom yang ingin Anda ubah.
Keketatan pencocokan nama
Mode validasi kepemilikan
ownership_validation_mode menentukan seberapa banyak bukti kepemilikan dompet yang diperlukan sebelum transfer dapat mengandalkan dompet tersebut:
FULL dan SIMPLIFIED, transfer berikutnya hanya memakai ulang dompet tersebut jika bukti yang diterima oleh mode tersebut untuk transfer itu mendukungnya.
Ketika inbound_auto_accept tidak menemukan dompet yang cocok di buku alamat, dompet kripto yang Anda catat dalam transaksi milik tepat satu pengguna akhir dapat mengidentifikasi pemiliknya.
Didit menambahkan dompet tersebut ke buku alamat pengguna akhir sebagai deklarasi mandiri Anda, dan dianggap terverifikasi kecuali mode-nya FULL. Didit tidak pernah menambahkan dompet yang sudah tercantum di buku alamat dengan nama lain pada rantai yang sama (eth dan ethereum), termasuk dompet yang dicatat sebagai milik VASP lain.
Pemeriksaan alamat yang dilakukan VASP lain sebelum mengirim (melalui GTR, Sygna dan VerifyVASP) juga mengikuti mode ini: pada FULL, dompet yang hanya dideklarasikan pengguna akhir tidak dilaporkan sebagai milik Anda.
Berbagi data
data_sharing_fields memilih kolom mana yang dikirim Didit kepada pihak lawan tentang pengguna Anda sendiri, dipisahkan untuk individu dan perusahaan:
- Individu dapat membagikan
name,wallet_address,address,national_id,customer_identification,date_of_birth, danplace_of_birth. Perusahaan menggunakan lima yang pertama. namedanwallet_addressselalu dikirim.- Jenis entitas yang tidak pernah Anda pilih membagikan setiap kolom. Daftar kosong juga merupakan pilihan: hanya nama dan dompet yang dibagikan.
PUTdigabungkan per jenis entitas, sehingga mengirimindividualtidak mengubah pilihancompanyyang tersimpan.- Pilihan yang tidak dapat memenuhi kewajiban pengirim dari rezim
jurisdictionAnda (EU TFR atau FATF Recommendation 16), termasuk daftar kosong, ditolak dengan400. Galatnya berada di bawahdata_sharing_fields, dengan kunci berdasarkan jenis entitas.
Pencocokan per kolom
matching_rules menentukan seberapa ketat setiap kolom data pihak lawan dibandingkan dengan data yang Anda miliki:
NONE, STRICT, CONTAINS, DEFAULT, atau FUZZY.
Bawaan: name mengikuti name_matching_strictness, date_of_birth dan address berupa NONE, dan account berupa STRICT.
Kolom yang dihilangkan tetap memakai default-nya, dan kolom yang tidak dibandingkan oleh jenis entitas (perusahaan tidak memiliki date_of_birth) ditolak dengan 400.
Ambang batas per yurisdiksi
threshold_amount ada karena cakupan Travel Rule berbeda-beda menurut regulator.
Didit menetapkan default 0.00 - posisi UE - sehingga setiap transfer dipertukarkan kecuali Anda menaikkannya secara sengaja:
threshold_amount ke angka yang ditetapkan regulator Anda; transfer di bawah angka tersebut langsung menghasilkan NOT_APPLICABLE tanpa pertukaran data identitas apa pun.
Ambang batas terus berubah - konfirmasikan angka terkini dengan penasihat kepatuhan Anda, dan jangan memperlakukan tabel ini sebagai nasihat hukum.
Model data IVMS 101
Standar industri untuk data yang dipertukarkan di bawah Travel Rule adalah IVMS 101 (interVASP Messaging Standard).travel_rule_details.originator_data dan travel_rule_details.beneficiary_data adalah payload individu dalam gaya IVMS 101: Didit membungkusnya dalam pembungkus asli setiap jalur - jalur TRP menukar blok IVMS101 (ivms101.2023, dilaporkan di kolom ivms_version transfer), jalur Sygna menggunakan varian IVMS terenkripsi ECIES, dan jalur GTR, TRUST, serta VERIFYVASP menggunakan pembungkus terenkripsi masing-masing - sehingga satu bentuk payload menjangkau setiap pihak lawan dalam format yang diharapkan protokolnya.
Didit membaca kunci berikut dari setiap payload individu saat menyusun pesan IVMS 101: first_name dan last_name (atau satu name atau full_name), date_of_birth, place_of_birth, residence_country (atau country), vendor_data (atau customer_identification), dan wallet_address.
Dua aturan praktis:
- Aksara Latin. IVMS 101 mensyaratkan nilai dalam aksara Latin; transliterasi nama yang secara asli ditulis dengan aksara lain. Pencocokan nama Didit membandingkan kumpulan token yang sudah dinormalisasi, sehingga perbedaan urutan dan huruf besar-kecil tidak menggagalkan pertukaran - tetapi aksara yang berbeda di kedua sisi akan menggagalkannya.
- Kirimkan data yang sudah Anda verifikasi. Ketika subjek di balik
vendor_dataadalah pengguna dengan verifikasi KYC Didit yang disetujui, Didit mengirimkan identitas terverifikasi, bukan nilai yang Anda ketik: lihat Data terverifikasi dan asal data. Untuk subjek lain, Didit mengirimkan persisoriginator_datayang Anda kirim, jadi bangunlah dari identitas yang Anda verifikasi saat onboarding, bukan dari kolom formulir yang belum diverifikasi. Itulah yang dituntut oleh frasa FATF “required and accurate originator information” (informasi pengirim yang wajib dan akurat). Pada jalurINTERNAL, aplikasi penerima juga menerimasubjectyang Anda kirim (nama,vendor_data, tanggal lahir, negara, dan alamat) sebagai pihak lawan dari transaksi masuknya.
Data terverifikasi dan asal data
Ketika subjek sebuah transfer adalah salah satu pengguna Anda, yaitu individu dengan verifikasi KYC yang disetujui, Didit menyusun sisi pertukaran tersebut dari data terverifikasi:- pengirim transfer keluar yang Anda buat dengan
POST /v3/transactions/; - penerima transfer masuk yang Anda laporkan dengan
POST /v3/transactions/, atau denganPOST /v3/travel-rule/inbound/ketikaholder_vendor_datapada dompet yang cocok menyebut pengguna tersebut.
POST /v3/transactions/, keduanya berlaku untuk transaksi yang transaction_category-nya adalah travel_rule selama Travel Rule aktif.
Nama terverifikasi, tanggal dan tempat lahir, nomor serta jenis dokumen, alamat, dan negara tempat tinggal (dari alamat tersebut) didahulukan atas nilai yang Anda kirim. Kolom yang tidak dimiliki verifikasi tetap menggunakan nilai Anda, begitu pula alamat lengkap yang Anda kirim ketika alamat terverifikasi tidak cukup lengkap untuk dikirimkan.
metadata transfer, pada objek travel_rule yang tertanam di transaksi, mencatat asal setiap kolom dan tempat nilai Anda berbeda:
*_provenance memetakan setiap kolom ke verified atau caller, dan *_verified_differences mencantumkan setiap kolom tempat Anda mengirim nilai yang berbeda dari nilai terverifikasi, tanpa memperhatikan huruf besar-kecil, spasi, dan kode negara dua atau tiga huruf. Selama data transfer masuk disamarkan, perbedaan tidak disertakan. Didit menghitung keduanya, sehingga salinan kunci ini, atau name_match, yang Anda kirim di travel_rule_details.metadata akan dibuang.
Mengirim IVMS 101 secara langsung
Selain objek dataroriginator_data dan beneficiary_data, travel_rule_details (pada POST /v3/transactions/) dan POST /v3/travel-rule/inbound/ menerima IVMS 101 asli:
- blok
originatordanbeneficiary, denganoriginatorPersonsataubeneficiaryPersonsyang berisinaturalPersonataulegalPerson, sertaaccountNumber; - blok yang sama di dalam objek
ivms101(atauIVMS101); - satu orang IVMS 101, atau satu blok utuh, sebagai
originator_dataataubeneficiary_data.
naturalPerson, atau legalPerson, yang menjadikan pihak tersebut sebuah perusahaan. originator_data atau beneficiary_data datar yang tidak kosong didahulukan atas blok untuk sisi yang sama.
400 dengan kunci sesuai jalurnya, misalnya {"travel_rule_details": {"originator.originatorPersons": ["must be a non-empty list of originator persons."]}}. Pada POST /v3/travel-rule/inbound/, kunci yang sama berada di tingkat teratas, di bawah ivms101. ketika Anda memakai pembungkus.
Data yang wajib diisi per rezim
Ketika Travel Rule aktif, transfer keluar yang mencapai atau melampaui ambang batas Anda harus memuat apa yang diwajibkan rezimnya, atau merespons400. Hanya sisi yang Anda kirim yang diperiksa, data terverifikasi dihitung untuk pengirim, dan galatnya berada di bawah travel_rule_details.originator_data atau travel_rule_details.beneficiary_data, misalnya "EU TFR requires the originator name." atau "FATF Recommendation 16 requires the beneficiary wallet address.":
data_sharing_fields, karena itulah yang dikirim oleh jalur; penerima diperiksa sebagaimana Anda kirimkan. Ketika transfer hanya memenuhi rezim dengan kolom yang tidak Anda bagikan, 400 menyebutkan persyaratan rezim lalu kolom yang dibagikan pengaturan Anda.
Nomor dokumen resmi adalah national_id (atau document_number), nomor identifikasi pelanggan adalah customer_identification (atau vendor_data), dan tanggal lahir adalah date_of_birth. beneficiary_data.wallet_address yang kosong diisi dari counterparty.payment_method.account_id sebelum pemeriksaan, dan penarikan UTXO yang output penerimanya disimpulkan Didit dari travel_rule_details.utxo dihitung sebagai memuatnya. Transfer Lightning yang tidak berlaku Travel Rule tidak diperiksa.
Travel Address
Travel Address adalah string terkode yang ringkas dan menunjuk ke endpoint inquiryTRP masuk milik VASP. Travel Address tidak pernah mengekspos URL mentah atau alamat dompet apa pun.
Setelah Travel Rule diaktifkan, Didit membuat travel_address milik Anda (dikembalikan dalam mode baca saja di pengaturan) sehingga Anda dapat membagikannya kepada VASP lain yang menjangkau Anda melalui jalur TRP.
Setiap dompet di buku alamat dompet Anda juga memiliki receiving_travel_address per dompet: inquiry yang dikirim ke dompet tersebut menyebutkan dompet itu, sehingga Didit tidak perlu mencarinya berdasarkan nomor rekening atau nama pemegang.
Host TRP publik Didit belum merespons VASP lain, sehingga penerimaan melalui TRP belum tersedia hingga host tersebut merespons: lihat Jaringan Travel Rule.
Saat Anda mengetahui Travel Address sebuah pihak lawan, simpan di entri buku alamat dompet tujuan agar Didit merutekan transfer untuk penerima tersebut langsung melalui TRP, bukan beralih ke email.
Didit memvalidasi Travel Address yang Anda simpan pada entri buku alamat dompet atau kirim di originating_vasp: setiap alamat harus diawali dengan ta dan didekode menjadi URL inquiry yang memuat t=i, sehingga placeholder seperti ta... akan mengembalikan 400.
beneficiary_data.travel_address pada transaksi tidak divalidasi: jika tidak dapat didekode, jalur TRP dilewati.
Enkodingnya adalah Base58Check dengan prefiks ta: host dan path endpoint (yang selalu memuat pasangan query t=i) ditambah checksum double-SHA-256 empat byte, lalu di-encode dengan base58.
Contoh Travel Address yang valid tampak seperti berikut dan panjangnya sekitar 100 karakter:
400 dengan "Invalid travel address.".
Ambil Travel Address yang valid dari respons pengaturan Anda sendiri, atau dari pihak lawan itu sendiri.
Pengujian tanpa kredensial jaringan
Anda tidak memerlukan keanggotaan GTR, TRUST, VerifyVASP, atau Sygna untuk menguji jalur yang tidak memerlukan keanggotaan. Anda tetap memerlukan kunci API Didit untuk aplikasi yang diuji.- Sandbox keluar: kirim transaksi
travelRuledari aplikasi sandbox. Setelah pemeriksaan ambang batas dan pemeriksaan dompet swakelola, Didit Test VASP akan meresponsnya di dalam Didit dengan skenario yang Anda pilih berdasarkan dompet atau nama penerima: diterima, ditolak, nama tidak cocok, tidak dapat dijangkau, timeout, atau swakelola. Tidak ada jaringan, email, atau pelanggan Didit lain yang menerima apa pun. - Sandbox masuk: minta VASP pengujian mengirim transfer kepada Anda dengan Trigger Test VASP Inbound Transfer, atau daftarkan sendiri dengan Register Inbound Travel Rule Transfer. Uji dompet yang tidak dikenal, dompet yang belum diverifikasi, ketidakcocokan nama penerima, dan dompet yang terverifikasi dan cocok. Skenario ini menguji keputusan inbound nyata tanpa menghubungi jaringan.
- Dua aplikasi produksi yang terkendali: gunakan rail
INTERNALdi antara dua aplikasi produksi milik Anda (aplikasi penerima dapat ditemukan dan membuktikan kendali atas dompet tujuan dengan pesan bertanda tangan atau setoran uji), atau pihak lawan TRP yang terkendali, untuk menguji pertukaran dua pihak tanpa kredensial jaringan komersial. Aplikasi produksi dapat menimbulkan biaya dan notifikasi normal; gunakan identitas dan pihak lawan uji yang Anda kendalikan.
Mengirim transfer
Sertakan transfer diPOST /v3/transactions/ dengan mengatur transaction_category ke travelRule (atau travel_rule) dan melampirkan objek travel_rule_details (alias: travelRule).
Blok travel_rule_details bersifat opsional, tetapi setelah Anda melampirkannya, travel_rule_details.status wajib diisi: blok tanpa field ini akan mengembalikan 400.
Ketika Travel Rule diaktifkan untuk aplikasi Anda, Didit mengabaikan nilai status yang Anda kirim dan menjalankan pertukaran data sendiri:
- Jika jumlahnya di bawah
threshold_amountyang Anda konfigurasikan, transfer langsung diselesaikan dengan statusNOT_APPLICABLEdan tidak ada negosiasi yang dilakukan. - Jika metode pembayaran pihak lawan menyatakan tujuan sebagai dompet swakelola (
payment_method.method_type: "unhosted_wallet"), tidak ada jalur yang dicoba. Transfer langsung masuk keUNCONFIRMED_OWNERSHIPdan widget kepemilikan dompet dibuat otomatis (lihat Dompet swakelola yang dinyatakan). - Jika tidak, jalur dijalankan sesuai urutan prioritas, dan jalur pertama yang dapat menjangkau pihak lawan akan membawa pertukaran data:
INTERNAL: tepat satu pelanggan Didit lain memegang bukti pesan bertanda tangan atau bukti setoran uji untukbeneficiary_data.wallet_address, yang dibuat setelah dompet terakhir kali berganti pemegang. Aplikasi Anda sendiri tidak pernah dihitung, dan jika pengguna akhir Anda memilih anggota jaringan Didit di widget kepemilikan dompet, hanya bukti anggota tersebut yang dihitung. Aplikasi pelanggan tersebut harus berstatus produksi (bukan sandbox), Travel Rule aktif, danis_discoverablediatur, serta merupakan VASP yang Anda sebutkan ketika mengirimcounterparty_vasp_leiataucounterparty_vasp_name. Dompet yang hanya dinyatakan sendiri, dibuktikan dengan tangkapan layar, belum diverifikasi, atau hanya tercantum di buku alamat tidak akan pernah menerima apa pun melaluiINTERNAL.TRP: aset transfer memiliki pemetaan Digital Token Identifier untuk jaringan transfer (lihat Pengidentifikasi aset TRP), dan payload membawabeneficiary_data.travel_address, atau entri buku alamat tujuan menyimpannya, atau pihak lawan ditemukan di direktori (melaluicounterparty_vasp_leiataucounterparty_vasp_name) dengan endpoint TRP.GTR,TRUST,VERIFYVASP,SYGNA: Anda telah menghubungkan keanggotaan Anda sendiri untuk jaringan tersebut di Marketplace, dan pihak lawan dapat diselesaikan menjadi ID jaringan (melalui kolom eksplisit atau entri direktori, lihat Kolom penyelesaian pihak lawan). Saat ini Didit belum memiliki keanggotaan platform di jaringan-jaringan ini (Didit sedang dalam proses onboarding sebagai penyedia), sehinggadisabled_networksbelum mengubah langkah ini.EMAIL:beneficiary_data.counterparty_vasp_emailtelah diisi, ataucounterparty_vasp_namediselesaikan menjadi entri direktori dengan email kepatuhan.
- Jika tidak ada jalur yang dapat menyelesaikan pihak lawan, Didit menjalankan rangkaian penemuan pihak lawan. Jika
vasp_attribution_enabledaktif, rangkaian ini mencakup atribusi analitik blockchain: dompet tujuan diselesaikan menjadi VASP pemiliknya, nama hasil atribusi ditulis kebeneficiary_data.counterparty_vasp_name(jika kosong) dan ke direktori, lalu jalur dijalankan ulang sekali. Dengan demikian, dompet yang diatribusikan ke VASP yang entri direktorinya memiliki endpoint TRP, ID jaringan, atau email kepatuhan akan dirutekan pada putaran kedua ini. - Jika pihak lawan masih belum terselesaikan, transfer berpindah ke
COUNTERPARTY_VASP_NOT_FOUND. Untuk transfer keluar, Didit membuat otomatis widget kepemilikan dompet (jikaauto_wallet_verificationaktif) agar transfer tetap dapat diselesaikan sebagai transfer dompet swakelola, dan Anda dapat menjalankan ulang perutean nanti denganaction: "resend"setelah memiliki data pihak lawan yang lebih baik.
AWAITING_COUNTERPARTY dan protocol: null, dan setiap hasil tiba sebagai webhook travel_rule.status.updated.
Pengidentifikasi aset TRP
TRP menyebut aset yang ditransfer dengan Digital Token Identifier (DTI) ISO 24165.
DTI mengidentifikasi token pada satu blockchain, sehingga token multi-chain memiliki satu DTI untuk setiap jaringan.
Didit mengirim transfer melalui TRP untuk aset-aset berikut:
USDC adalah yang diterbitkan oleh penerbit token dalam white paper MiCA-nya.
Untuk token multi-chain, transfer harus menyebut jaringannya di transaction_details.crypto_params.crypto_chain (misalnya CELO, BASE, OP, ARB, atau POL).
Tanpa jaringan, atau pada jaringan yang tidak memiliki pemetaan, transfer tidak dikirim melalui TRP dan Didit mencoba jalur yang tersisa: jaringan interoperabilitas terlebih dahulu, kemudian email.
USDT belum dipetakan.
Token tanpa pemetaan DTI, seperti stablecoin milik perusahaan, memerlukan penerbitnya untuk mendaftarkan DTI ke otoritas registrasi ISO 24165, satu per token per blockchain.
Setelah DTI tersedia, hubungi dukungan Didit dengan setiap DTI, blockchain-nya, dan jumlah angka desimal token, lalu Didit akan menambahkan pemetaannya.
Permintaan TRP masuk yang membawa DTI per jaringan yang dipetakan dicatat dengan mata uang token, jumlah dalam desimal token, dan jaringannya.
Penemuan pihak lawan
Transfer yang hanya membawa alamat dompet tetap dapat mencapai pihak lawannya selama ada pihak yang dapat mengidentifikasinya. Sebelum transfer keluar dinyatakan tidak dapat dirutekan, Didit memeriksa, sesuai urutan berikut, dan berhenti pada langkah pertama yang menyebut VASP dengan rute:discovery pada transfer mencantumkan setiap langkah yang dijalankan beserta outcome-nya (match, miss, atau skipped), reason yang dapat dibaca mesin, vasp dan rail yang ditemukan, serta stempel waktu.
VASP yang Anda atau pengguna akhir pilih lebih diutamakan daripada setiap langkah otomatis: discovery tidak pernah menggantinya dengan tebakannya sendiri.
Jika tidak ada langkah yang menyebutkan pihak lawan, transfer berpindah ke COUNTERPARTY_VASP_NOT_FOUND, atau COUNTERPARTY_VASP_NOT_REACHABLE jika sebuah VASP telah disebutkan tetapi tidak satu pun rutenya tersedia untuk aplikasi Anda.
Transfer kemudian memuat reason (awaiting_end_user, no_directory_match, directory_match_no_route, atau picked_member_without_proven_wallet ketika anggota yang dipilih pengguna akhir belum membuktikan kepemilikan dompet) dan daftar next_actions:
url pada tindakan yang dilakukan pengguna akhir.
Ketika tindakan kepemilikan dompet sedang menunggu, blok action_required transaksi (tipe wallet_ownership) memuat reason dan next_actions yang sama, sehingga klien yang sudah mengikuti action_required menampilkan pemilih tanpa tindakan tambahan.
Kolom penentuan pihak lawan
Semua yang diketahui Didit tentang pihak lawan berasal daritravel_rule_details.beneficiary_data.
Kolom-kolom berikut menentukan resolusi jalur; semuanya bersifat opsional:
Bentuk chain
Pada chain akun (chain EVM, Solana, Tron) transfer memindahkan dana dari satu alamat ke alamat lain, dan Didit membaca kedua dompet langsung dari transaksi. Tiga bentuk lain memerlukan lebih banyak data, dan hasil resolusi Didit untuk bentuk-bentuk tersebut ada di transfer sebagaichain_details (kosong, {}, pada chain akun).
chain_details.originator dan chain_details.beneficiary masing-masing memuat address, memo, dan source, sumber asalnya, dan pencocokan serta perutean membaca dompet dari sana terlebih dahulu.
Transfer UTXO
Transaksi Bitcoin, Litecoin, Bitcoin Cash, atau Dogecoin menggunakan input dari sejumlah alamat dan membayar sejumlah output, sebagian di antaranya dikembalikan ke pengirim sebagai kembalian. Kirim input dan output sebagaitravel_rule_details.utxo (jumlah dalam satuan koin itu sendiri, sebagai string desimal), dan Didit menyimpulkan apa yang tidak Anda deklarasikan:
- Pengirim:
originator_data.wallet_addressjika Anda mengirimkannya, jika tidak, alamat input yang memberikan kontribusi terbesar (source: largest_input). - Penerima: dompet yang dideklarasikan, jika tidak, satu-satunya output yang tidak dikirim kembali ke alamat input sebagai kembalian (
only_non_change_output), jika tidak, satu output yang membayar jumlah transfer (amount_match).
chain_details.warnings menandai hal-hal yang tidak sesuai: declared_originator_not_an_input, declared_beneficiary_not_an_output, beneficiary_output_ambiguous (tidak ada satu output pun yang dapat dibedakan) dan beneficiary_output_amount_differs.
utxo pada rantai lain mengembalikan 400, dan setiap daftar memuat paling banyak 1,000 entri.
Deposit yang dilaporkan menggunakan objek utxo yang sama (lihat Pendaftaran sunrise setelah deposit).
Jaringan memo dan tag
Pada XRP, Stellar (XLM), EOS, Cosmos (ATOM), dan Hedera (HBAR), exchange menerima setiap pelanggan di satu alamat bersama dan membedakannya melalui tag tujuan atau memo. Oleh karena itu, memo menjadi bagian dari dompet: kirimkan sebagaipayment_method.memo pada peserta, atau sebagai memo di originator_data / beneficiary_data (alias destinationTag), dan Didit membandingkan alamat dan memo secara bersamaan.
- Entri buku alamat dengan memo hanya cocok dengan transfer yang menyebutkan memo tersebut. Entri tanpa memo cocok dengan seluruh alamat. Transfer yang tidak menyebutkan memo tidak pernah mencapai entri yang memilikinya: pada alamat bersama, deposit tanpa tag-nya tidak menjadi milik siapa pun.
- Alamat X XRP memuat tag di dalamnya: Didit memisahkannya menjadi alamat klasik dan tag (
source: x_address), sehingga dompet yang didaftarkan dalam salah satu bentuk akan cocok dengan transfer dalam bentuk lainnya. - Setiap memo pada alamat bersama merupakan metode pembayaran tersendiri pada transaksi.
- Yang diterima oleh setiap jaringan: tag tujuan XRP adalah bilangan bulat dari 0 hingga 4294967295 (angka JSON diterima); memo Stellar berupa teks hingga 28 byte, id 64-bit, atau hash 32-byte dalam format heksadesimal; EOS menerima hingga 256 byte, Cosmos hingga 256 karakter, Hedera hingga 100 byte. Memo pada rantai yang tidak memilikinya (Bitcoin, rantai EVM, Solana, Tron, Litecoin, Bitcoin Cash, Dogecoin, Lightning) mengembalikan
400.
Lightning
Pembayaran Lightning tidak memiliki alamat penerima on-chain: pembayar memegang permintaan pembayaran. Pada transfer kripto bitcoin atau Lightning,payment_method.account_id dapat berisi permintaan tersebut, dan Didit mengidentifikasi penerima dari permintaan itu tanpa menghubungi jaringan mana pun:
chain_details.beneficiary (source: invoice_payee), pada rantai LIGHTNING, dan isi permintaan tersebut tersimpan di chain_details.lightning.
Jika permintaan tidak menyebutkan penerima pembayaran, transfer keluar berstatus NOT_APPLICABLE dengan alasannya di chain_details.not_applicable_reason dan di timeline-nya: LIGHTNING_NO_PAYEE_IDENTIFIER, LIGHTNING_BOLT12_BLINDED_PAYEE, atau LIGHTNING_LNURL_NAMES_NO_PAYEE.
Sebuah nilai hanya dibaca sebagai Lightning pada bitcoin, pada LIGHTNING, atau ketika tidak ada rantai yang disebutkan (Lightning Address hanya pada bitcoin atau LIGHTNING): pada rantai lain, nilai tersebut adalah alamat milik rantai itu sendiri.
INTERNAL hanya mencapai pelanggan Didit lain melalui dompet yang kendalinya telah dibuktikan oleh pelanggan tersebut dengan pesan bertanda tangan atau deposit uji, dan bukti tersebut saat ini tersedia untuk Bitcoin, rantai EVM, Solana, dan Tron.
Oleh karena itu, pada jaringan memo, Lightning, Litecoin, Bitcoin Cash, dan Dogecoin, transfer tidak pernah mencapai pelanggan Didit lain melalui INTERNAL.
Pencocokan memo, tag, dan Lightning tetap berlaku untuk buku alamat Anda sendiri: transfer masuk, deposit yang dilaporkan, dan permintaan TRP ke dompet Anda.Memperbarui dompet pengirim
Penarikan sering dideklarasikan dari dompet utama pelanggan Anda, dan disiarkan dari alamat mana pun yang memegang koin tersebut. Catat dompet tempat dana sebenarnya keluar denganPATCH /v3/transactions/{transaction_id}/travel-rule/:
- Hanya transfer keluar, dan tidak pernah transfer yang berstatus
CANCELLEDatauEXPIRED(409). - Jika input UTXO transfer diketahui, dompet harus salah satu dari input tersebut (jika tidak,
400). Kirim jugamemopada jaringan memo. - Hanya catatan yang diubah: tidak ada yang dikirim ulang ke pihak lawan dan statusnya tetap.
chain_details.originatormenjadi dompet baru dengansource: updated,timelinemencatat dompet sebelumnya dan dompet baru, dan pihak lawanINTERNALdari transfer tersebut diperbarui dengan cara yang sama.
Atribusi analitik blockchain
Ketika Anda hanya menyertakan alamat dompet, Didit tetap dapat mengetahui siapa pihak di seberangnya. Jika tidak ada jalur yang dapat merutekan transfer, Didit mencocokkan dompet tujuan dengan data atribusi analitik blockchain - analisis yang sama dengan yang mendukung skrining transaksi kripto mengetahui dompet mana milik exchange dan kustodian mana. Atribusi hanya dijalankan pada transfer keluar yang memuat dompet tujuan danchain (lihat Kolom penentuan pihak lawan); tanpa rantai, atribusi dilewati.
Ketika dompet diatribusikan ke entitas yang dikenal, Didit:
- Mencatat atribusi pada transfer:
beneficiary_data.counterparty_vasp_namediisi (jika Anda tidak memasukkannya), dan metadata transfer memuat blokvasp_attributiondengan nama entitas, jenis entitas, negara, dansource: "blockchain_analytics". - Menambahkan entitas ke direktori VASP (atau mencocokkan entri yang sudah ada), sehingga atribusi tetap konsisten di seluruh transfer.
- Menjalankan ulang jalur sekali dengan nama hasil atribusi - entri direktori yang sudah memuat endpoint TRP membuat transfer dirutekan segera, alih-alih berakhir di
COUNTERPARTY_VASP_NOT_FOUND.
custom_values.aml_screening_trigger pada transaksi diatur ke travel_rule_attribution sehingga Anda dapat melihat bahwa skrining dijalankan karena perutean Travel Rule memerlukannya.
Jika pemantauan kripto sudah melakukan skrining pada dompet yang sama dalam transaksi ini, hasil yang tersimpan digunakan kembali - tidak ada panggilan analitik kedua, dan tidak ada biaya tambahan.
Atribusi tidak pernah memblokir pembuatan transaksi: jika pencarian analitik gagal atau saldo Anda tidak mencukupi, transfer langsung berlanjut ke COUNTERPARTY_VASP_NOT_FOUND dan tidak ada biaya yang dikenakan untuk percobaan tersebut.
Pada action: "resend", atribusi yang sudah dicatat sebelumnya digunakan kembali, bukan dikueri ulang.
Nonaktifkan seluruh langkah dengan vasp_attribution_enabled: false di pengaturan.
Lihat Harga untuk mengetahui bagaimana panggilan atribusi ditagihkan.
Saat Travel Rule dinonaktifkan, travel_rule_details (termasuk status yang diberikan pemanggil, baik status lama maupun status saat ini) tetap dicatat pada transaksi, tetapi secara pasif - tidak ada jalur yang dijalankan.
Gunakan ini untuk mengisi data kepatuhan yang sudah Anda lacak dengan proses Anda sendiri.
Transfer keluar yang pasif tidak memulai pertukaran, sehingga ditagih sebagai Skrining Transaksi, bukan pada jalur Travel Rule.
Saat Travel Rule diaktifkan, permintaan ini diarahkan melalui jalur EMAIL, karena menyebutkan email kepatuhan pihak lawan dan tidak ada jalur sebelumnya yang dapat menjangkau penerima:
originator_dataadalah data yang Anda kirim, karena subjek contoh tidak memiliki verifikasi KYC yang disetujui; untuk pengguna yang terverifikasi, Didit membangunnya dari data terverifikasi (lihat Data terverifikasi dan asal-usul data). JalurEMAILhanya menampilkan kepada penerima kolom pengirim yang Anda bagikan didata_sharing_fields.beneficiary_data.chainbernilaiETHkarena permintaan tidak menyebutkan jaringan, sehingga Didit mengambilnya dari mata uang.statusbernilaiAPPROVEDkarena tidak ada aturan yang memproses transaksi; aturan Anda sendiri dapat menetapkan status lain.- Kontak kepatuhan menerima tautan pengambilan, dan transfer selesai, gagal pada kecocokan nama, atau ditolak saat mereka merespons, atau kedaluwarsa jika mereka tidak merespons (lihat Pengambilan melalui email).
protocol masih null karena jalur dipilih setelah respons (misalnya EMAIL saat Anda memberikan counterparty_vasp_email): Ambil transaksi menampilkannya setelah dipilih, dan setiap webhook travel_rule.status.updated berikutnya memuatnya di rail.
Jika dompet penerima milik pelanggan Didit lain yang telah membuktikan kendali atasnya, jalur INTERNAL menyelesaikan seluruh pertukaran tepat setelah respons, dan webhook tersebut sudah melaporkan COMPLETED (atau COUNTERPARTY_MISMATCHED_DATA). Saat nama tidak cocok, transfer Anda berstatus COUNTERPARTY_MISMATCHED_DATA dan pelanggan lain tidak menerima apa pun.
Tanpa counterparty_vasp_email, dan ketika baik jalur maupun atribusi tidak dapat menjangkau penerima, transfer kemudian berakhir dengan COUNTERPARTY_VASP_NOT_FOUND dengan tindakan wallet_ownership pada transaksi.
travel_rule yang tertanam pada transaksi memuat kolom transfer itu sendiri (uuid, status, protocol, required, obligations_count, originator_data, beneficiary_data, metadata), yang ditentukan dan dibandingkan oleh Didit (chain_details, name_match, data_match, mismatched_fields, dan kolom maskering data_masked dan data_unmasked), serta kolom yang menunjukkan posisinya: direction, rail, counterparty_vasp, delivery, discovery, reason, dan next_actions (lihat Mengapa transfer macet).
Setiap baris GET /v3/transactions/ memuat blok yang sama, atau null untuk transaksi tanpa transfer.
Endpoint transfer khusus di bawah ini juga mengembalikan kolom tersebut, ditambah ivms_version, ownership_confirmed, deadline_at, timeline, dan created_at, tetapi tanpa obligations_count atau metadata.COMPLETED setelah Anda menyiarkannya on-chain:
COMPLETED - jika tidak, API mengembalikan 409.
Jika berhasil, transfer keluar dan pasangannya pada jalur INTERNAL sama-sama beralih ke FINISHED, dan payment_txn_id transaksi diisi dengan hash yang Anda berikan.
Pada jalur TRP, Didit juga mengirim hash ke callback konfirmasi pihak lawan.
Untuk membatalkan transfer yang belum mencapai status akhir, kirim {"action": "cancel"} ke endpoint yang sama sebagai gantinya.
Pasangan pada jalur INTERNAL ikut dibatalkan, dan pada jalur TRP, setelah pihak lawan menyetujui permintaan, Didit mengirim pembatalan ke callback konfirmasinya.
Transfer yang sudah berstatus FINISHED, CANCELLED, atau EXPIRED mengembalikan 409.
Permintaan yang tidak memiliki payment_txn_id maupun action yang didukung mengembalikan 400.
Pada transfer yang melalui GTR, VERIFYVASP atau SYGNA, Didit melaporkan hash on-chain (atau pembatalan) ke jaringan setelah respons, dengan percobaan ulang yang sama; delivery pada respons menunjukkan pesan tersebut.
Untuk mencoba ulang transfer keluar yang tidak dapat menjangkau pihak lawannya - yang saat ini berstatus COUNTERPARTY_VASP_NOT_FOUND, COUNTERPARTY_VASP_NOT_REACHABLE, atau NOT_ENOUGH_COUNTERPARTY_DATA - pertama-tama perbaiki data pihak lawan, misalnya dengan menambahkan travel_address pada entri dompet tujuan, kontak untuk entri direktori pihak lawan, atau dengan mendaftarkan VASP tersebut di direktori.
Kemudian kirim {"action": "resend"} ke endpoint yang sama.
Didit memulai ulang tenggat konfirmasi dan memasukkan kembali urutan perutean dari awal, menggunakan data yang tersimpan pada transfer: respons menunjukkan transfer kembali ke AWAITING_COUNTERPARTY (dengan resend queued pada timeline-nya), dan hasilnya dikirim sebagai webhook travel_rule.status.updated.
Permintaan pengiriman ulang yang dikirim saat percobaan sebelumnya masih berjalan akan dikirim setelah percobaan tersebut selesai.
Status lain, atau transfer masuk, mengembalikan 409.
{"action": "beneficiary_vasp", "beneficiary_vasp": "<directory VASP id>"} (id dari GET /v3/travel-rule/vasps/).
Transfer diarahkan ke VASP tersebut dan dikirim ulang.
Hanya transfer keluar dengan status COUNTERPARTY_VASP_NOT_FOUND, COUNTERPARTY_VASP_NOT_REACHABLE atau NOT_ENOUGH_COUNTERPARTY_DATA yang menerimanya; status lain mengembalikan 409, dan id yang tidak dikenal mengembalikan 404.
Mengapa transfer macet
Transfer dengan statusCOUNTERPARTY_VASP_NOT_FOUND atau COUNTERPARTY_VASP_NOT_REACHABLE menjelaskan mengapa macet dan apa yang membuatnya berjalan lagi, setiap kali transaksinya dibaca.
Blok travel_rule dari GET /v3/transactions/{transaction_id}/, dari respons 201 POST /v3/transactions/, dan dari setiap baris GET /v3/transactions/ memuatnya, begitu pula objek transfer yang dikembalikan oleh endpoint transfer:
reasonadalah penyebab yang dapat dibaca mesin,""untuk status lainnya.next_actionsberisi tindakan yang memajukan transfer,[]untuk status lainnya.deliveryadalah pesan terbaru yang harus dikirimkan transfer kepada pihak lawan:kind,status(QUEUED,SENDING,RETRYING,DELIVERED, atauFAILED),rail,attempts,last_error,next_attempt_at, dandelivered_at, ataunulljika tidak ada pesan yang harus dikirim.discoveryadalah tempat Didit mencari pihak lawan, dengan satu entri untuk setiap langkah yang dijalankan:step,outcome(match,miss, atauskipped),reason,vasp,rail, danat.
email_undeliverable dan delivery_failed berasal dari pengiriman yang gagal dan hanya muncul pada COUNTERPARTY_VASP_NOT_REACHABLE.
Pengiriman yang gagal menentukan reason terlebih dahulu, sehingga pihak lawan yang berhasil ditemukan Didit tidak pernah dilaporkan sebagai pihak yang tidak dapat ditemukan.
Empat yang lain berasal dari jejak penemuan, pada status mana pun.
reason-nya dihapus.
Entri linimasa dari transisi yang disebabkan pengiriman gagal membawa nilai yang sama pada reason.
Jika penyedia email menolak email kepatuhan dari contoh transfer di atas, blok travel_rule pada transaksinya terbaca sebagai berikut, dalam bentuk ringkas:
delivery sesuai dengan reason, karena pengiriman itu sendiri ditolak.
Penolakan pada pengingat, atau bounce yang dilaporkan kemudian, membiarkan delivery.status tetap DELIVERED: email pertama memang terkirim.
Baca reason, bukan delivery, untuk mengetahui mengapa transfer tertahan.
Untuk memperbaikinya, berikan kembali email kepatuhan pihak lawan, lalu kirim ulang:
update_compliance_email menyimpan alamat tersebut sebagai beneficiary_data.counterparty_vasp_email pada transfer ini: alamat itu hanya berlaku untuk transfer ini dan tidak masuk ke entri direktori maupun daftar kontak mana pun.
Status tidak berubah, linimasa mencatat compliance email updated, dan transfer tetap memiliki reason: email_undeliverable hingga pengiriman ulang mengirim permintaan ke alamat baru.
Hanya transfer keluar dalam COUNTERPARTY_VASP_NOT_FOUND, COUNTERPARTY_VASP_NOT_REACHABLE, atau NOT_ENOUGH_COUNTERPARTY_DATA yang menerima tindakan ini; transfer lain menjawab 409, dan compliance_email yang tidak ada atau formatnya salah menjawab 400.
Dompet swakelola yang dideklarasikan
Ketika pelanggan Anda memberi tahu bahwa tujuannya adalah dompet swakelola (unhosted) miliknya sendiri, deklarasikan dompet tersebut pada transaksi, alih-alih membiarkan perutean menemukan bahwa tidak ada VASP di baliknya: atur jenis metode pembayaran pihak lawan menjadiunhosted_wallet.
- Tidak ada rail yang dicoba - tidak ada VASP pihak lawan untuk bertukar data - dan transfer langsung dibuat dalam
UNCONFIRMED_OWNERSHIP. - Ketika
auto_wallet_verificationaktif (nilai default), Didit secara otomatis membuat sesi widget kepemilikan dompet yang terikat pada transaksi dan mengembalikannya dalam blokaction_requiredtransaksi; SDK akan membukanya secara otomatis pada pengiriman sisi klien. - Setelah pelanggan membuktikan kendali atas dompet, transfer menjalankan pencocokan nama penerima dan maju ke
COMPLETED(atauCOUNTERPARTY_MISMATCHED_DATAjika pencocokan gagal).
UNCONFIRMED_OWNERSHIP bukan status yang dapat dikirim ulang - selesaikan pembuktian kepemilikan (atau batalkan) alih-alih memanggil action: "resend".
Penerimaan
Mengonfirmasi kepemilikan dompet
Transfer akan menunggu di statusUNCONFIRMED_OWNERSHIP dalam dua kasus:
- Transfer masuk mengarah ke entri buku alamat yang kepemilikannya belum terverifikasi.
- Dompet pihak lawan dinyatakan sebagai dompet swakelola (
counterparty.payment_method.method_type: "unhosted_wallet"), baik pada penarikan keluar maupun setoran masuk. Lihat Dompet swakelola yang dinyatakan.
confirmed (wajib, boolean) dan wallet_address (opsional).
Endpoint ini menerima transfer dalam status berikut, dan mengembalikan 409 dengan {"detail": "Transfer is not awaiting ownership confirmation."} untuk status lainnya:
UNCONFIRMED_OWNERSHIP, di kedua arah.ON_HOLDpada transfer masuk.UNCONFIRMED_OWNERSHIP,ON_HOLDatauCOUNTERPARTY_MISMATCHED_DATApada transfer masukTRP, sehingga petugas kepatuhan dapat menyelesaikan pertanyaan pihak lawan secara manual.
INTERNAL, registrasi sunrise, atau dompet swakelola yang dinyatakan):
confirmed: truemenandai entri buku alamat dompet yang cocok sebagai kepemilikannya terverifikasi, lalu menjalankan pencocokan nama terhadapholder_nameentri tersebut. HasilnyaCOMPLETEDjika lolos, danCOUNTERPARTY_MISMATCHED_DATAjika tidak. Pasangan relINTERNAL, jika ada, mendapat hasil yang sama. Untuk dompet swakelola yang dinyatakan,confirmed: truemencatat bahwa pelanggan Anda telah memverifikasi siapa yang mengendalikan dompet pihak lawan, dan menyelesaikan transfer (COMPLETED), baik keluar maupun masuk. Transfer masuk yang depositnya sudah diselesaikan kemudian langsung berlanjut keFINISHED.confirmed: falsememindahkan kedua sisi transfer keCOUNTERPARTY_VASP_GENERAL_DECLINE.- Entri yang cocok dicari di buku alamat Anda hanya berdasarkan alamat dompet, tanpa jaringan blockchain.
Menyelesaikan
ON_HOLDmasuk tanpa entri yang cocok akan membuat entri daribeneficiary_data.wallet_addresstransfer dan menandainya sebagai terverifikasi. Dompet swakelola yang dinyatakan adalah pengecualian: dompet didaftarkan di buku alamat Anda sebagai kepemilikannya terverifikasi, seperti dijelaskan di bawah. Dalam kasus lain, entri yang tidak ada mengembalikan409dengan{"detail": "wallet address entry no longer available"}, yang juga dikembalikan untuk entri yang sudah dihapus.
TRP, panggilan yang sama menjawab pertanyaan pihak lawan:
confirmed: truememerlukan alamat pembayaran untuk dikembalikan, yang diambil dariwallet_addresspada permintaan, lalu dari entri yang cocok, lalu daribeneficiary_data.wallet_address. Jika ketiganya tidak ada, permintaan mengembalikan400dengan{"wallet_address": ["wallet_address is required to approve."]}. Didit membuat atau memverifikasi entri, mengirim callback penyelesaian pertanyaan ke pihak lawan, menetapkanownership_confirmed, dan memindahkan transfer keCOMPLETED.confirmed: falsemengirim respons penolakan dan memindahkan transfer keCOUNTERPARTY_VASP_GENERAL_DECLINE.- Jika endpoint callback pihak lawan tidak dapat dijangkau, permintaan mengembalikan
502dan transfer tetap berada di status saat ini. Pada persetujuan, entri buku alamat dompet tetap dibuat atau ditandai sebagai terverifikasi.
COUNTERPARTY_MISMATCHED_DATA.
Jika transfer sama sekali tidak menyebut dompet pihak lawan, sertakan wallet_address dalam body permintaan.
Jika transfer maupun permintaan tidak menyediakan alamat dompet, permintaan ditolak dengan 400.
- Transfer jaringan yang sudah dijawab melalui jaringannya (transfer VerifyVASP, atau transfer GTR atau Sygna Bridge yang sudah diputuskan) mengembalikan
409(lihat Transfer dari jaringan).
INTERNAL baru tidak pernah menunggu di sini: transfer hanya sampai kepada pelanggan yang sudah membuktikan kendali atas dompet tersebut. Transfer INTERNAL lama yang masih menunggu dari sebelum aturan itu tetap menyembunyikan detail pengirim sampai Anda membuktikan kendali atas dompet (pesan yang ditandatangani atau setoran uji), dan mengonfirmasinya mengembalikan 409 sampai Anda melakukannya. Menolaknya tetap berfungsi.
Ketika pihak lawan menjawab bahwa dompetnya adalah dompet swakelola (saat ini Didit Test VASP memberikan jawaban itu di sandbox), mengonfirmasi menambahkan dompet ke buku alamat Anda atas nama penerima dan menjalankan pencocokan nama. Kecocokan menyelesaikan transfer dan menandai dompet sebagai terverifikasi.
Transfer dari jaringan
Didit juga dapat menerima transfer Travel Rule yang dikirim pihak lawan melaluiGTR, VERIFYVASP atau SYGNA.
Penerimaan diaktifkan oleh Didit untuk setiap jaringan secara terpisah, dan saat ini belum ada yang diaktifkan: penerimaan juga memerlukan registrasi endpoint Didit di setiap jaringan, dan Didit belum memiliki keanggotaan di jaringan-jaringan ini.
Transfer TRUST tidak dapat diterima.
Setelah sebuah jaringan diaktifkan, pesan yang dikirimkannya ditangani sebagai berikut:
- Perutean. Pesan sampai ke aplikasi Anda ketika pesan itu menyebut kode peserta dari keanggotaan terhubung Anda sendiri di jaringan tersebut. Pesan yang dialamatkan ke keanggotaan Didit sendiri hanya sampai kepada Anda jika Anda adalah satu-satunya pelanggan Didit aktif yang telah membuktikan kendali atas dompet penerima. Selain itu, pesan ditolak, sehingga tidak ada pelanggan yang pernah menerima transfer pelanggan lain.
- Keputusan. Didit membuat transfer masuk di aplikasi Anda dan memutusnya seperti permintaan TRP: pencocokan dompet, kepemilikan, pencocokan nama, dan
inbound_auto_accept. - Sekali saja. Jaringan mengirim ulang pesan hingga pesan itu dijawab. Pesan yang dikirim ulang menerima jawaban yang sama dengan yang diterima salinan pertama, dan tidak ada yang dibuat atau diputuskan dua kali.
- Peninjauan Anda, melalui
GTRdanSYGNA. Transfer yang menunggu Anda (UNCONFIRMED_OWNERSHIP,ON_HOLDatauCOUNTERPARTY_MISMATCHED_DATA) diputuskan denganPOST .../travel-rule/ownership/:confirmed: truemenyetujuinya (sertakanwallet_addressjika transfer tidak menyebutkannya) danconfirmed: falsemenolaknya. Didit menjawab jaringan setelah respons, dengan mekanisme coba lagi yang sama. Transfer yang sudah dijawab sebelumnya mengembalikan409. - Tidak ada jawaban lanjutan melalui
VERIFYVASP. VerifyVASP mengambil jawabannya saat ia bertanya, sehingga transfer yang memerlukan peninjauan Anda langsung ditolak dan tidak dapat diputuskan kemudian (409).
Data pihak lawan yang disamarkan
Sampai kepemilikan dompet dikonfirmasi, data pribadi pihak lawan pada transfer masuk dikembalikan dalam bentuk disamarkan, bukan dihilangkan. Huruf pertama setiap kata tetap ditampilkan, dan routing dompet, chain, serta VASP tetap dapat dibaca.data_masked bernilai true, dan pihak lawan dalam detail transaksi, daftar, serta ekspor CSV disamarkan dengan cara yang sama.
Setelah kepemilikan dikonfirmasi, nilai sebenarnya muncul dan data_unmasked mencatat entri audit:
reason berisi ownership_confirmed, wallet_proof, address_book_match, own_verified_wallet, inquiry_approved (Anda menyetujui inkuiri TRP atau pesan GTR atau Sygna), known_payment_method (dompet pengguna akhir dalam catatan Anda sendiri memberikan jawaban) atau travel_address (Travel Address per dompet menyebutkan dompet tersebut).
Transfer masuk INTERNAL membawa data_unmasked dengan reason: wallet_proof sejak dibuat, karena hanya penerima yang telah membuktikan kepemilikan atau kendali atas dompet yang menerimanya.
actor berisi email pengguna konsol atau label kunci API, dan kosong untuk keputusan otomatis.
Laporan Log transfer Travel Rule (CSV dan PDF) menyamarkan nama pada transfer masuk dengan cara yang sama sampai kepemilikan dikonfirmasi. Laporan yang Anda serahkan kepada regulator, seperti goAML XML dan laporan PDF untuk regulator, memuat data pihak lawan yang sebenarnya.
Umpan balik ketidakcocokan
TransferCOUNTERPARTY_MISMATCHED_DATA kini menyebutkan kolom yang berbeda.
data_match berisi hasil perbandingan dan mismatched_fields berisi daftar kolom tersebut.
Keduanya hanya memuat nama kolom dan hasil, tidak pernah nilai, sehingga tetap dapat dibaca saat data disamarkan:
TRP penolakan setelah ketidakcocokan memberi tahu VASP pengirim kolom mana yang berbeda, misalnya “Data penerima tidak cocok dengan pemegang dompet: nama”.
Yang diketahui VASP lain dibatasi secara sengaja: selama nama belum cocok, nama adalah satu-satunya kolom yang dilaporkan (mismatched_fields: ["name"], setiap kolom lain not_compared), dan setelah nama cocok, setiap kolom yang berbeda disebutkan. Ini berlaku untuk sisi pengirim pada pertukaran INTERNAL dan untuk penolakan TRP.
Nama yang kosong di kedua sisi bernilai not_compared dan bukan ketidakcocokan, dan negara dicocokkan berdasarkan negara yang dimaksud, sehingga ES dan ESP dianggap sama.
Skor kecocokan nama
Setiap transfer yang namanya dibandingkan memuatname_match, dan entri timeline yang menentukan hasilnya memuat objek yang sama di samping detail-nya:
scoreadalah kemiripan antara dua nama lengkap, dari 0 sampai 100, dan0jika salah satu nama kosong.matchedadalah hasil padastrictness, sehingga keduanya bisa berbeda:FUZZYmemutuskan berdasarkan rasio kemiripannya sendiri0.85.matched_namesadalah kata-kata dari nama transfer yang ditemukan dalam nama lainnya;mismatched_namesadalah kata-kata yang dimiliki salah satu sisi tetapi tidak dimiliki sisi lainnya.methodbernilainone,exact_token,token_subset,token_containmentatausequence_ratio, untukNONE,STRICT,DEFAULT,CONTAINSdanFUZZY.compared_withbernilaiwallet_holder(pemegang yang tercatat untuk dompet) ataucounterparty_vasp(nama yang diberikan pihak lawan di halaman respons email, atau jawaban Didit Test VASP).- Hasil transfer mengikuti
data_match, yang membandingkan setiap kolom, sehingga sebuah transfer dapat berstatusCOUNTERPARTY_MISMATCHED_DATAsementaraname_match.matchedbernilaitrue. name_matchada pada objek transfer yang dikembalikan oleh endpoint Travel Rule dan padatravel_ruleyang tertanam di transaksi, dan bernilainullsampai nama dibandingkan. Daftar transfer dan webhook tidak memuatnya.- Nama disembunyikan selama pihak-pihak disamarkan, dan pada salinan pertukaran
INTERNALmilik pelanggan lain.
Pesan dan permintaan dokumen
Dua VASP dapat menyelesaikan transfer yang disengketakan di dalam Didit, bukan lewat email.GET dan POST /v3/transactions/{transaction_id}/travel-rule/messages/ mencantumkan dan mengirim pesan pada suatu transfer:
kindbernilaiMESSAGE(default) atauDOCUMENT_REQUEST. Permintaan dokumen membutuhkan minimal satu entri direquested_documents(hingga 10); pesan membutuhkanbody(hingga 5000 karakter) atau sebuah file.reply_tomenunjuk pesan sebelumnya pada transfer yang sama. Balasan dari pihak seberang yang memuat dokumen memenuhi permintaan dokumen yang dijawabnya, danfulfilled_atdiisi pada pesan tersebut. Balasan Anda sendiri tidak pernah memenuhi permintaan Anda sendiri.- Kirim multipart dengan
filesuntuk melampirkan hingga 5 file berukuran masing-masing 10 MB, berupa PDF, PNG, JPEG atau WebP. Didit memeriksa isi setiap file, bukan hanya tipe yang dideklarasikan, dan file lain menyebabkan permintaan mengembalikan400padafiles(“Attach PDF, PNG, JPEG or WebP files only.”). - Sebuah transfer menampung hingga 100 pesan, dengan hingga 20 di antaranya dapat memuat lampiran (masing-masing hingga 5 file), dihitung dari kedua sisi; jika melebihi salah satu batas, permintaan dijawab
400. Lampiran pesan tidak dihitung sebagai dokumen transaksi itu sendiri. - Pesan berjalan melalui jalur
INTERNALdanEMAIL. PadaINTERNAL, pelanggan Didit lain melihat pesan di sisinya dalam pasangan tersebut. PadaEMAIL, pihak lawan menerima email dan menjawab di portal pengambilan. Jika email pemberitahuan tidak dapat dikirim, pesan tetap disimpan dan permintaan dijawab201. - Permintaan dijawab
409dengan alasan didetailuntuk transfer melaluiTRP,GTR,TRUST,VerifyVASP, atauSygna(protokol tersebut tidak membawa pesan), transfer yang belum memiliki pihak lawan, transferINTERNALyang datanya tidak cocok dengan pemegang dompet (tidak ada yang sampai ke penerima), transferINTERNALyang penerimanya belum membuktikan kendali atas dompet (di kedua sisi, sampai hal itu terjadi), transferEMAILyang pihak lawannya tidak lagi memiliki alamat email kepatuhan, dan transferEMAILyang tautan pengambilannya sudah kedaluwarsa atau transfernya sudah ditutup. - Tidak ada webhook yang terpicu saat pihak lawan membalas. Baca endpoint pesan.
- Email yang memberi tahu pihak lawan tentang pesan baru dikirim dalam bahasa Inggris.
Buku alamat dompet
Daftarkan dompet yang Anda kendalikan agar transfer masuk (jalurINTERNAL, inkuiri TRP masuk, dan pendaftaran setelah deposit) dapat dicocokkan dengan dompet tersebut, dengan POST/GET /v3/travel-rule/wallet-addresses/ dan PATCH/DELETE /v3/travel-rule/wallet-addresses/{entry_uuid}/.
PATCH menerima holder_name, holder_vendor_data, entity_type, dan travel_address, dan hanya mengembalikan keempat kolom tersebut.
DELETE menghapus entri (204). Alamatnya dibebaskan untuk didaftarkan ulang dan segera berhenti mencocokkan transfer baru.
memo-nya pada jaringan memo, dan dibatasi oleh chain.
Ketika transfer membawa chain, entri hanya cocok jika chain-nya bernilai sama (tanpa membedakan huruf besar dan kecil) atau kosong.
Nama chain dibandingkan sebagai teks, tidak diterjemahkan, sehingga entri yang tersimpan sebagai ethereum tidak cocok dengan transfer yang chain-nya ETH.
Transfer keluar mengambil chain-nya dari beneficiary_data.chain, lalu transaction_details.crypto_params.crypto_chain, lalu custom_properties.crypto_chain, lalu mata uang (misalnya ETH, atau untuk USDT dan USDC chain yang disimpulkan dari payment_reference_id). Chain hanya ditetapkan jika merupakan chain yang dikenali Didit. Pendaftaran setelah deposit mengambilnya dari kolom chain-nya, dalam huruf kecil.
Permintaan masuk TRP mengabaikan chain: permintaan dicocokkan berdasarkan alamat, atau, jika permintaan tidak menyebut dompet, berdasarkan nama penerima terhadap entri terverifikasi Anda.
POST .../travel-rule/ownership/ juga mencocokkan berdasarkan alamat saja.
Ketika beberapa entri cocok, jalur INTERNAL dan pendaftaran setelah deposit memprioritaskan entri yang kepemilikannya terverifikasi, lalu yang paling lama. Pencarian TRP keluar mengambil entri tertua yang menyimpan travel address.
Permintaan masuk TRP dan endpoint kepemilikan mengambil salah satu entri yang cocok, jadi simpan satu entri per alamat jika memungkinkan.
Jalur INTERNAL tidak mencocokkan entri sama sekali ketika entri terverifikasi untuk alamat tersebut ada di lebih dari satu aplikasi lain.Mengimpor dompet secara massal
Impor hingga 10.000 dompet dalam satu panggilan denganPOST /v3/travel-rule/wallet-addresses/import/, dalam format JSON ({"entries": [...]} atau array langsung (tanpa pembungkus)) atau sebagai file CSV UTF-8 berukuran maksimal 5 MB dengan baris header.
Satu baris menyebut dompet dengan address-nya, dengan address_hash (SHA-256 dari alamat yang sudah diubah menjadi huruf kecil, 64 karakter hex atau 44 karakter base64), atau keduanya, serta kolom entri apa pun di atas. Kirim hash saja untuk mendaftarkan dompet tanpa mengungkap alamatnya: hash itu mencocokkan transfer ke alamat tersebut seperti entri lain, dan dapat dibuktikan dengan widget verifikasi kepemilikan dompet.
created, existing (dompet, chain, dan memo yang sama sudah ada dalam daftar dan tidak diubah), duplicate (mengulang baris sebelumnya, disebutkan di duplicate_of_row), atau failed dengan errors-nya. Satu baris yang buruk tidak menggagalkan baris lain: responsnya 200 jika tidak ada baris yang gagal dan 207 jika ada, dengan jumlah di total, created, existing, duplicate, dan failed.
Sel CSV yang kosong dianggap tidak dikirim, dan kolom yang tidak dibaca impor diabaikan, sehingga ekspor dari alat lain dapat diimpor apa adanya.
Pada GET /v3/travel-rule/transfers/, setiap baris memuat originator_memo dan beneficiary_memo di samping kedua dompet.
Pengambilan email untuk pihak lawan yang tidak dapat dijangkau
Ketika tidak ada jalur protokol yang dapat menjangkau pihak lawan, Didit beralih keEMAIL: Didit mengirim tautan pengambilan sekali pakai ke beneficiary_data.counterparty_vasp_email (atau email yang diperoleh dari beneficiary_data.counterparty_vasp_name melalui registri direktori VASP).
Penerima tidak memerlukan akun Didit atau kunci API. Token pada tautan itulah autentikasinya.
Berikut cara permintaan dikirim:
- Ke alamat yang tepat.
counterparty_vasp_emailyang Anda kirim adalah satu-satunya penerima. Jika tidak, Didit menulis ke hingga tiga alamat: kontak pihak lawan yang belum memantul (kontak Anda sendiri lebih dulu, lalu kontak platform, yang pernah merespons lebih dulu), kemudian email kepatuhan entri direktori jika masih ada slot tersisa. Setiap alamat menerima emailnya sendiri. - Atas nama Anda. Email berasal dari alamat Didit dengan nama “nama hukum Anda via Didit”, dalam bahasa yurisdiksi pihak lawan (bahasa Inggris jika tidak diketahui), dan tautan membuka halaman respons dalam bahasa tersebut. Anda tidak menerima salinan: pantau linimasa transfer.
- Dengan pengingat. Hingga pihak lawan merespons, Didit mengingatkannya 72, 24, dan 6 jam sebelum batas waktu, setidaknya 12 jam setelah permintaan atau pengingat terakhir, dan tidak pernah setelah batas waktu.
- Dengan pantulan yang ditangani. Pantulan atau keluhan spam menandai kontak yang dijangkau sebagai tidak valid beserta alasannya, dan linimasa transfer mencatatnya. Kontak platform kemudian tidak valid untuk setiap pelanggan Didit. Kontak aplikasi Anda sendiri hanya tidak valid untuk aplikasi Anda. Ketika pengiriman email Didit berhenti mengirim ke suatu alamat sama sekali (setelah pantulan permanen, keluhan spam, atau berhenti berlangganan), setiap kontak di alamat itu ditandai tidak valid (
suppressed), dan kontak tersebut kembali valid ketika pengiriman ke alamat itu dilanjutkan. Ketika tidak ada alamat yang tersisa untuk dikirimi, transfer menjadiCOUNTERPARTY_VASP_NOT_REACHABLEdengan alasan dari server email penerima di linimasanya. Pantulan permanen atau keluhan spam padacounterparty_vasp_emailyang Anda kirim langsung menyebabkan hal ini, karena alamat itu satu-satunya penerima. Pantulan sementara (soft_bounce) pada alamat itu, atau pada email kepatuhan entri direktori, membiarkan permintaan tetap terbuka untuk pengingat.
reference adalah uuid transfer. originator_data dan ivms_request IVMS 101 yang dibangun darinya hanya memuat kolom data pengirim yang Anda bagikan di data_sharing_fields; nama dan dompet selalu disertakan. fiat_amount dan fiat_currency kosong jika Anda tidak mengirim nilai yang dikonversi, contact mengembalikan nilai ?contact= pada tautan, dan decline_reasons mencantumkan nilai yang dapat diterima oleh decline_reason. join_invitation.eligible bernilai true selama pihak lawan memiliki undangan aktif untuk bergabung ke Didit; tautan undangan itu sendiri hanya dikirim melalui email.
Endpoint ini mengembalikan jumlah yang tersimpan apa adanya, sehingga menyertakan 18 angka desimal penuh, bukan bentuk terpangkas yang digunakan objek detail transaksi.
decision bernilai accept atau decline.
Pada accept, beneficiary_name yang dikirim dibandingkan dengan beneficiary_data.name pada transfer sesuai aturan nama Anda: COMPLETED jika cocok, COUNTERPARTY_MISMATCHED_DATA jika tidak.
Pihak lawan dapat mengirim respons IVMS 101 lengkap sebagai ivms_response sebagai gantinya; nama penerima di dalamnya kemudian menjadi acuan utama, bukan beneficiary_name.
Pada decline, transfer berpindah ke COUNTERPARTY_VASP_GENERAL_DECLINE. Pihak lawan dapat memberikan decline_reason dari decline_reasons, dengan decline_detail (maksimal 512 karakter, wajib untuk other), dan linimasa transfer Anda mencatatnya, misalnya counterparty declined: The beneficiary is not our customer.
Respons berupa {"status": "..."} yang dihasilkan, ditambah decline_reason setelah penolakan. Setelah pihak lawan memberikan jawaban, kedua endpoint mengembalikan 410.
Kedua endpoint mengembalikan 404 untuk token yang tidak dikenal dan 410 setelah jendela waktunya tertutup, yaitu ketika transfer sudah tidak lagi berstatus AWAITING_COUNTERPARTY, atau ketika tenggat konfirmasinya (confirmation_timeout_hours setelah pembuatan atau kirim ulang terakhir) sudah lewat.
Pihak lawan membaca dan menjawab melalui tautan pickup dengan GET dan POST /v3/travel-rule/pickup/{token}/messages/.
Pihak lawan tidak memerlukan kunci API, hanya menerima lampiran PDF, PNG, JPEG, atau WebP, dan mendapatkan 410 setelah tautan kedaluwarsa atau transfer ditutup.
Pesan yang Anda kirim menampilkan nama VASP Anda sebagai author dan sebagai uploaded_by pada lampiran, tidak pernah menampilkan orang atau kunci API di baliknya.
Deposit yang belum dipasangkan
Deposit masuk bisa tiba sebelum data Travel Rule dari VASP pengirim. Deposit seperti itu tetap berstatusAWAITING_COUNTERPARTY atau NOT_ENOUGH_COUNTERPARTY_DATA sampai data tersebut tiba.
Cantumkan deposit yang masih menunggu dengan kunci API yang memiliki izin transaksi:
GET /v3/travel-rule/transfers/, dibatasi pada deposit masuk yang menunggu data dari VASP pengirim.
Ketika data sudah tiba sebagai pesan Travel Rule terpisah yang diterima, pasangkan keduanya secara manual:
{transaction_uuid} adalah deposit.
transaction_id adalah transaksi dari pesan Travel Rule yang diterima.
Panggilan ini mengembalikan { "deposit": ..., "message": ... }.
Panggilan ini mengembalikan 404 jika salah satu transaksi sudah tidak ada, dan 409 dengan travel_rule_match_conflict (“Deposit ini tidak dapat dicocokkan lagi.”) jika salah satu sisi sudah berpindah status.
Pendaftaran sunrise setelah deposit
Ketika deposit kripto diselesaikan on-chain sebelum pertukaran Travel Rule apa pun terjadi, karena VASP pengirim tidak dapat dihubungi atau Anda mendaftarkan deposit historis, daftarkan deposit tersebut setelahnya denganPOST /v3/travel-rule/inbound/.
originating_vasp.travel_address harus berupa Travel Address yang nyata dan valid dengan checksum; placeholder akan mengembalikan 400 dengan "Invalid travel address.".
originating_vasp.lei harus kosong atau 20 karakter dalam format LEI (18 huruf atau angka, diikuti 2 angka); selain itu akan mengembalikan 400 dengan "Invalid LEI: expected 20 alphanumeric characters (ISO 17442).".
Didit hanya memeriksa format ini, bukan digit checksum ISO 17442.
travelRule masuk (atau menggunakan ulang deposit masuk yang sudah Anda kirim dengan hash dan dompet yang sama, jika belum memiliki transfer Travel Rule) dan mencocokkan transfer dengan buku alamat dompet Anda berdasarkan alamat dan memo-nya:
- Tidak ada entri yang cocok ->
ON_HOLD. Selesaikan denganPOST .../travel-rule/ownership/:confirmed: truemenambahkan dompet ke buku alamat Anda sebagai terverifikasi dan menjalankan pencocokan nama; jika cocok, transfer berpindah keCOMPLETED, laluFINISHED. - Entri ada tetapi kepemilikan belum terbukti ->
UNCONFIRMED_OWNERSHIP. - Nama penerima tidak cocok dengan
holder_namepada entri ->COUNTERPARTY_MISMATCHED_DATA. - Entri terverifikasi dan nama cocok ->
COMPLETED, lalu langsungFINISHED(deposit sudah diselesaikan).
txn_id transaksi baru adalah tr-in- ditambah 80 karakter pertama dari txid, dan hash 12 karakter dari txid dan dompet.
created bernilai true (HTTP 201) saat panggilan ini mendaftarkan deposit, dan false (HTTP 200) saat txid dan wallet_address yang sama sudah terdaftar; dalam kasus itu, transfer yang sudah ada dikembalikan tanpa perubahan.
Pada jalur entri terverifikasi, kedua transisi terjadi sebelum endpoint merespons, jadi respons sinkron sudah menampilkan status akhir FINISHED - langkah perantara COMPLETED tetap tercatat di timeline transfer.
Setiap transisi memicu webhook travel_rule.status.updated (COMPLETED dan FINISHED masing-masing memicu satu).
Saat Didit membuat transaksi baru, Didit mengirim transaction.created terlebih dahulu, lalu event-event ini setelahnya.
Pendaftaran tidak dikenakan biaya Travel Rule maupun biaya pemantauan.
Saat pemantauan kripto diaktifkan dan chain termasuk yang dapat disaring oleh Didit, deposit yang baru dibuat juga menjalani skrining dan ditagih satu kali dengan tarif Wallet Verification & Screening.
Widget verifikasi kepemilikan dompet
Untuk memindahkan transfer keluar dariUNCONFIRMED_OWNERSHIP - atau untuk memverifikasi dompet terlebih dahulu sebelum transfer apa pun masuk - buat sesi widget verifikasi kepemilikan dompet yang di-hosting dengan POST /v3/travel-rule/widget-session/ dan arahkan pelanggan Anda ke url yang dikembalikan. Widget membuktikan kendali atas dompet melalui penandatanganan pesan (termasuk akun smart contract EVM, melalui ERC-1271 dan ERC-6492), tes Satoshi, tangkapan layar, atau pernyataan mandiri, lalu menandai entri buku alamat yang sesuai sebagai terverifikasi agar pertukaran dapat dilanjutkan.
Tangkapan layar adalah pengecualian: tangkapan layar tidak pernah memverifikasi dompet dengan sendirinya, jadi tim kepatuhan Anda meninjau dan mengonfirmasi transfer di UNCONFIRMED_OWNERSHIP dengan POST .../travel-rule/ownership/.
Lihat Widget verifikasi kepemilikan dompet untuk alur lengkap, metode pembuktian, dan catatan penting bahwa widget harus dibuka di browser sungguhan - jangan pernah dibuka di dalam webview SDK seluler.
Direktori
GET /v3/travel-rule/vasps/ mencari direktori VASP: entri direktori bersama beserta anggota jaringan Didit. Setiap baris menunjukkan cara aplikasi Anda dapat menjangkau VASP tersebut saat ini.
search cocok dengan sebagian nama atau alias, LEI yang persis sama, atau domain (counterparty.example atau URL di domain tersebut). Persempit hasil dengan:
risk dan responsiveness hanya mengembalikan entri direktori. Hasil diurutkan berdasarkan nama dan dipaginasi dengan limit (default 50) dan offset. Jaringan, kode negara, tingkat risiko, atau status responsivitas yang tidak dikenal merespons 400 dengan menyebut kolomnya. GET /v3/travel-rule/vasps/{vasp_id}/ mengembalikan satu baris berdasarkan id-nya. Profil VASP Anda sendiri tidak pernah muncul dalam hasil Anda sendiri.
dd_status, dd_score, dd_score_breakdown, dd_assessed_at, dd_score_semantic, risk_level, responsiveness dan essential_checks memuat penilaian uji tuntas bersama untuk entri direktori. decision, entity_screening dan questionnaires adalah catatan aplikasi Anda sendiri tentang VASP, dan tidak ada pelanggan lain yang dapat melihatnya. Lihat Uji tuntas pihak lawan untuk arti masing-masing, dan gunakan kolom aturan pihak lawan untuk membatasi akses berdasarkan kolom tersebut, bukan dengan percabangan inline. Anggota jaringan Didit tidak dinilai: dd_status berisi COMPLETED, dd_score berisi null, risk_level kosong, dan rinciannya kosong.
Rute
routes mencantumkan cara aplikasi Anda dapat mengirim ke VASP, sesuai urutan yang dicoba oleh mekanisme perutean bertingkat, dan reachable bernilai true ketika setidaknya satu rute berstatus available:
TRPketika entri memiliki endpoint TRP yang diverifikasi oleh direktori.GTR,TRUST,VERIFYVASP,SYGNAketika sebuah jaringan mencantumkan VASP di bawah suatu kode. Rute hanyaavailablejika aplikasi Anda dapat mengirim melalui jaringan tersebut saat ini (via: own_membershipuntuk keanggotaan terhubung milik Anda sendiri,via: didit_membershipuntuk keanggotaan Didit). Jika tidak, rute berstatusunavailabledenganreason: no_membershipataureason: network_switched_off, dan tidak pernah ditampilkan sebagai cara untuk menjangkau VASP. Keanggotaan jaringan Didit belum aktif, sehingga saat ini rute jaringan hanya tersedia melalui keanggotaan yang Anda hubungkan di Marketplace.EMAILketika ada kontak kepatuhan untuk entri tersebut.INTERNALuntuk anggota jaringan Didit.
TRISA muncul di bawah networks dan memberi tahu Anda siapa VASP tersebut di TRISA, tetapi Didit tidak memiliki jalur TRISA, sehingga tidak pernah menjadi rute.
Aplikasi sandbox hanya mengirim ke Didit Test VASP, sehingga tidak ada rute direktori yang tersedia baginya: setiap rute berstatus unavailable dengan reason: sandbox_application, setiap baris memiliki reachable: false, dan reachable=true tidak mengembalikan baris apa pun.
Merek dan entitasnya
Merek yang beroperasi melalui beberapa entitas yang diatur adalah satu baris yangentities-nya merupakan entitas hukum penerima transfernya; baris entitas menunjuk kembali ke mereknya di umbrella. Transfer yang menyebut merek dikirim ke salah satu entitasnya, dipilih dari semua entitas: entitas di yurisdiksi yang dinyatakan di beneficiary_data.counterparty_vasp_jurisdiction, atau jika tidak ada, entitas yang ditautkan atribusi analitik blockchain ke dompet tujuan, atau jika tidak ada yurisdiksi yang dinyatakan, satu-satunya entitas merek tersebut. Baru setelah itu entitas tersebut harus dapat dijangkau; jika tidak, transfer tidak pernah dikirim ke entitas lain atau ke merek sebagai gantinya. Ketika tidak ada entitas yang cocok (dua entitas sama-sama cocok, atau tidak ada satu pun entitas yang berada di yurisdiksi yang dinyatakan), rute merek itu sendiri yang digunakan, dan tanpa rute tersebut transfer berstatus COUNTERPARTY_VASP_NOT_FOUND. Entitas hukum mana yang menerima data pengirim tidak pernah ditebak, dan tidak pernah ditentukan oleh entitas mana yang kebetulan memiliki kontak.
Beberapa entri yang diberi nama sama, misalnya perusahaan grup yang memakai nama dagang yang sama, dibedakan dengan aturan yang sama: entri di yurisdiksi yang dinyatakan, atau jika tidak, entri yang ditautkan atribusi analitik blockchain. Jika keduanya tidak memilih satu pun, tidak ada yang digunakan, dan detailnya dihitung sebagai tidak menamai entri direktori mana pun.
Kontak
contacts adalah alamat yang menjadi tujuan pengiriman oleh jalur EMAIL. Kontak scope: platform melayani setiap pelanggan Didit: Didit mengkurasi kontak tersebut (source: staff), atau alamat di domain VASP itu sendiri membalas permintaan melalui tautan respons (source: learned). Kontak scope: application bersifat pribadi bagi aplikasi Anda: yang Anda tambahkan (source: application), dan alamat di luar domain VASP yang membalas salah satu permintaan Anda (source: learned). Transfer mengirim email ke kontak milik aplikasi Anda terlebih dahulu, lalu ke kontak platform yang pernah membalas (verified_at terisi), lalu ke kontak lainnya.
Kelola kontak milik aplikasi Anda dengan API kontak pihak lawan:
GET /v3/travel-rule/counterparty-contacts/mencantumkan setiap kontak yang dapat dikirimi email oleh aplikasi Anda, termasuk kontak platform dan kontak yang gagal dikirimi email, dari yang terbaru, dipaginasi denganlimitdanoffset. Filter dengan?counterparty=danidentri direktori; nilai yang bukan UUID merespons400.POSTmenambahkan kontak pribadi (counterparty,email, dannameopsional) dan merespons201. Menambahkan alamat yang sudah tercatat untuk entri tersebut di antara kontak Anda akan mengembalikan kontak itu. Entri yang tidak dikenal merespons400("No directory entry with this id.").DELETE /v3/travel-rule/counterparty-contacts/{contact_uuid}/menghapus salah satu kontak milik Anda (204). Kontak platform tidak dapat dihapus dan merespons404.
is_invalid: true, dengan invalid_reason (hard_bounce, soft_bounce, spam_complaint atau suppressed), invalid_detail dan invalid_at, dan jalur EMAIL akan melewatinya. created_by kosong pada kontak platform dan pada kontak yang ditambahkan oleh kunci API.
Cara entri masuk ke direktori
- Registri interim MiCA dari ESMA untuk penyedia layanan aset kripto, dibaca setiap minggu: nama, LEI, dan negara anggota asal setiap penyedia.
- Direktori publik TRISA, dibaca setiap minggu: identitas setiap anggota, negaranya, dan daftarnya di TRISA. Daftar yang tidak lagi ditampilkan oleh direktori selama tiga minggu akan dihapus.
- Registri LEI global mengisi LEI, nama hukum lain, dan negara sebuah entri, serta menemukan LEI sebuah entri berdasarkan nama hukum persisnya di negaranya.
- Atribusi analitik blockchain menambahkan atau mencocokkan VASP yang memiliki dompet tujuan, dan menyimpan nama yang diatribusikan sebagai alias.
- Staf Didit mengkurasi entri: pengenal perutean dan daftar jaringan yang telah mereka verifikasi, kontak kepatuhan, alias, merek beserta entitasnya, duplikat yang digabungkan, dan entri yang disembunyikan.
originating_vasp pada transfer masuk atau Travel Address, tetap berada pada transfer pelanggan tersebut dan tidak pernah mengubah entri bersama. Entri dicocokkan terlebih dahulu berdasarkan LEI, lalu berdasarkan nama atau alias yang persis sama, dan diperkaya, bukan digandakan.
Jaringan Didit
Profil VASP Anda adalah anggota jaringan Didit, sehingga pelanggan Didit lain dapat menemukannya di direktori dan di pemilih VASP pengguna akhir, hanya jika semua kondisi berikut terpenuhi:- aplikasi Anda berada di lingkungan produksi (bukan sandbox) dan Travel Rule aktif;
is_discoverablebernilaitruedanlegal_namesudah diisi;compliance_emailsudah diisi dan dikonfirmasi: kirim konfirmasi denganPOST /v3/travel-rule/settings/compliance-email/confirmation/dan buka tautan yang dikirim lewat email. Mengubah alamat memerlukan konfirmasi baru;- Didit belum menandai aplikasi sebagai aplikasi uji coba, demo, atau internal.
INTERNAL sendiri mengirimkan dana ke dompet yang telah Anda buktikan kepemilikannya, sebagaimana dijelaskan di Mengirim transfer: jalur ini hanya memerlukan aplikasi Anda berada di lingkungan produksi, Travel Rule aktif, dan is_discoverable, bukan kondisi lain dalam daftar ini.
GET /v3/travel-rule/settings/ mengembalikan didit_network: listed, compliance_email_confirmed, dan di missing setiap kondisi yang belum terpenuhi (travel_rule_off, sandbox_application, not_discoverable, legal_name_missing, compliance_email_missing, compliance_email_unconfirmed, excluded_by_staff, internal_organization).
Pengenal perutean
Perutean keluar memeriksa entri direktori setiap kali transfer Anda menyebut pihak lawan dengancounterparty_vasp_lei atau counterparty_vasp_name (alias juga berfungsi). Sebuah entri membawa satu pengenal untuk setiap jaringan tempat ia dapat dijangkau, sebuah endpoint TRP yang telah diverifikasi beserta kontak kepatuhannya, dan routes menunjukkan mana di antaranya yang dapat digunakan aplikasi Anda. Anda selalu dapat melewati direktori untuk satu transfer dengan menyertakan kolom eksplisit di Kolom resolusi pihak lawan.
Uji tuntas pihak lawan
Sebelum dana pelanggan Anda sampai ke VASP lain, Anda perlu tahu siapa VASP tersebut dan apakah Anda menerimanya. Uji tuntas terhadap pihak lawan terdiri dari dua lapisan:- Penilaian bersama. Setiap entri direktori memiliki skor uji tuntas, tingkat risiko, status responsivitas, dan laporan pemeriksaan esensial. Didit menghitungnya dari data platform itu sendiri, sehingga setiap pelanggan melihat nilai yang sama.
- Catatan Anda sendiri. Keputusan Anda terhadap VASP, skrining sanksi dan media negatif terhadapnya, serta kuesioner uji tuntas yang Anda pertukarkan dengannya hanya menjadi milik aplikasi Anda. Pelanggan lain tidak pernah melihatnya, dan catatan tersebut tidak pernah mengubah entri bersama.
id yang ditampilkan direktori untuk mengaksesnya.
Skor dan tingkat risiko
dd_score berada dalam rentang 0 hingga 100, dan semakin tinggi semakin aman. Setiap hasil menyatakannya di dd_score_semantic, yang selalu bernilai higher_is_safer. risk_level adalah kelompok tempat skor tersebut berada:
dd_score_breakdown menampilkan setiap komponen sebagai {points, max, reason, detail}: max adalah bobot komponen tersebut, reason adalah kode yang dapat dibaca mesin dan dapat Anda terjemahkan, dan detail adalah penjelasan satu baris dalam bahasa Inggris.
history membaca permintaan yang sama dengan responsivitas, tanpa jendela waktu: pertukaran dengan COMPLETED atau FINISHED dihitung sebagai berhasil, sedangkan pertukaran dengan EXPIRED, COUNTERPARTY_MISMATCHED_DATA, atau COUNTERPARTY_VASP_GENERAL_DECLINE dihitung sebagai gagal. Pembatalan adalah tindakan pengirim sendiri dan tidak pernah dihitung.
Didit menghitung ulang penilaian ketika sebuah pertukaran dengan entri tersebut selesai, rampung, kedaluwarsa, mengalami ketidaksesuaian, atau ditolak; ketika entri diperbarui atau dikurasi; dan untuk setiap entri dalam pembaruan direktori mingguan. dd_assessed_at menunjukkan kapan penilaian terakhir dijalankan. Entri yang belum pernah dinilai tidak memiliki dd_assessed_at, memiliki dd_score bernilai 0, dan risk_level kosong, jadi baca risk_level, bukan skor mentah. Anggota jaringan Didit tidak dinilai: dd_score mereka bernilai null, risk_level kosong, dan dd_score_breakdown kosong.
Pemeriksaan esensial
essential_checks adalah laporan singkat tentang empat pemeriksaan yang dijalankan Didit pada setiap entri direktori, hanya dari sumber terverifikasi platform, tidak pernah dari data yang dilaporkan pelanggan:
checks menampilkan status-nya (pass, fail, atau unknown jika tidak ada sumber dalam catatan yang dapat memutuskannya), reason yang dapat dibaca mesin, dan detail dalam bahasa Inggris satu baris. passed, failed, unknown, dan total menghitung jumlahnya, level bernilai essential, dan checked_at menunjukkan kapan laporan dibuat. Komponen essentials menilai proporsi pemeriksaan yang sudah diputuskan dan lulus, sehingga pemeriksaan unknown tidak menambah maupun mengurangi nilai entri. Laporan kosong hingga pembaruan direktori mingguan pertama kali memeriksa sebuah entri, dan selalu kosong untuk anggota jaringan Didit.
Responsivitas
responsiveness menunjukkan apakah VASP menanggapi permintaan Travel Rule:
total menghitung permintaan yang dimulai oleh pelanggan Didit kepada VASP dalam 90 hari terakhir dan sudah memiliki hasil yang diputuskan, sedangkan answered menghitung permintaan yang dijawab VASP:
- Dihitung: permintaan yang dikirim melalui jalur jaringan atau protokol, dan permintaan yang dikirim melalui email ke alamat bersama, yaitu alamat kepatuhan entri atau kontak platform.
- Tidak pernah dihitung: permintaan yang dikirim melalui email ke alamat yang dimasukkan oleh seorang pelanggan, atau ke kontak pribadi pelanggan. Pertukaran tersebut tetap berada dalam riwayat transfer pelanggan itu dan tidak pernah memberi label pada VASP untuk pengguna lain.
- Dijawab:
COMPLETED,FINISHED,COUNTERPARTY_VASP_GENERAL_DECLINE, atauCOUNTERPARTY_MISMATCHED_DATA. Penolakan atau ketidaksesuaian data adalah jawaban: VASP tersebut telah merespons. - Tidak dijawab:
EXPIRED. - Bukan keduanya: setiap status lain. Permintaan
CANCELLEDadalah tindakan pengirim sendiri,COUNTERPARTY_VASP_NOT_REACHABLEdapat menjadi kegagalan di sisi pengirim, dan permintaan yang masih berjalan belum diputuskan.
UNKNOWN dengan jumlah nol. Tindak lanjuti pihak lawan yang tidak responsif dengan kebijakan non-responsif atau preset travel-rule-counterparty-unresponsive.
Keputusan Anda terhadap pihak lawan
Catat keputusan tim kepatuhan Anda terhadap pihak lawan denganPUT /v3/travel-rule/vasps/{vasp_id}/decision/:
- Keputusan bersifat privat bagi aplikasi Anda: pelanggan lain tidak pernah melihatnya, dan keputusan itu tidak pernah mengubah entri bersama.
- Keputusan tidak mengubah apa pun dengan sendirinya dan tidak pernah mengubah cara transfer dirutekan. Keputusan itu sampai ke transaksi Anda melalui kolom aturan
counterparty_dd_status: pasang preset, atau tulis aturan Anda sendiri yang memakai kolom tersebut. - Keputusan terhadap sebuah merek berlaku untuk setiap entitas miliknya yang belum punya keputusan sendiri, dan entitas tersebut menampilkan merek itu di
inherited_from. Keputusan terhadap entitas menggantikan keputusan merek untuk entitas tersebut. GETmengembalikan keputusan yang berlaku, atau{"decision": null}.DELETEmenghapus keputusan Anda sendiri dan mengembalikan keputusan yang berlaku setelahnya: keputusan merek untuk sebuah entitas, jika tidak ada makanull. Endpoint ini menjawab404ketika aplikasi Anda tidak memiliki keputusan sendiri terhadap pihak lawan tersebut.reasonbersifat opsional, maksimal 255 karakter, dan setiapPUTmenggantinya.decided_byadalah pengguna konsol yang membuat atau terakhir mengubah keputusan, dan kosong jika keputusan dibuat oleh kunci API.
Skrining pihak lawan
Skrining pihak lawan memeriksa VASP pihak lawan itu sendiri, sebagai sebuah perusahaan, terhadap sanksi dan media negatif. Fitur ini bersifat opt-in dan dikenakan biaya: aktifkan dengancounterparty_screening_enabled di pengaturan Anda. Selama fitur ini nonaktif, tidak ada yang diskrining atau ditagih.
- Penagihan. Setiap skrining baru dikenakan harga Skrining AML Perusahaan milik organisasi Anda.
GET /v3/travel-rule/vasps/{vasp_id}/screening/mengembalikanprice,fresh_days, dan apakah skriningenabled, tanpa biaya. Skrining yang usianya kurang dari 30 hari dianggap masih baru:POSTmengembalikannya lagi dengan200danoutcome: reusedserta tidak menagih apa pun, kecuali Anda mengirimrefresh: true. Skrining baru menjawab201denganoutcome: screened. Aplikasi sandbox tidak pernah diskrining atau ditagih. - Skrining otomatis. Ketika skrining aktif, Didit juga menskrining pihak lawan yang dituju oleh pertukaran keluar saat pertukaran itu dimulai, sebelum aturan Anda dievaluasi terhadap transaksi, dengan penggunaan ulang dan penagihan yang sama. Penolakan atau kegagalan di tahap ini tidak pernah menggagalkan transfer.
- Hasil.
statusbernilaiApprovedketika tidak ada kecocokan yang mungkin perlu ditinjau, danIn ReviewatauDeclineduntuk kecocokan yang mungkin terkait sanksi atau media negatif.flaggedbernilaitrueselama skrining baru berstatusIn ReviewatauDeclined. - Dampak. Selama skrining terakhir Anda terhadap pihak lawan ditandai dan skrining tetap aktif,
counterparty_risk_levelbernilaiHIGHdi aturan Anda, sehingga presettravel-rule-counterparty-high-risk, setelah dipasang, menahan transfernya.risk_levelbersama di direktori tidak berubah. - Privasi. Skrining bersifat privat bagi aplikasi Anda: pelanggan lain tidak pernah melihatnya, dan skrining itu tidak pernah mengubah entri bersama. Direktori menampilkan skrining terakhir Anda sebagai
entity_screening. - Penolakan.
409ketika skrining nonaktif, untuk aplikasi sandbox, atau ketika skrining pihak lawan yang sama sedang berjalan.403dengancode: insufficient_creditsketika saldo Anda tidak cukup untuk menutup harga.502ketika skrining tidak dapat diselesaikan. Tidak satu pun dari penolakan ini menagih apa pun.
Kuesioner uji tuntas
Mintalah jawaban uji tuntas dari pihak lawan dengan kuesioner standar Didit.POST /v3/travel-rule/vasps/{vasp_id}/questionnaires/ mengirimkannya melalui email ke alamat kepatuhan yang tercatat untuk pihak lawan, dengan tautan sekali pakai menuju halaman jawaban:
- Tujuan pengiriman.
sent_toharus berupa alamat kepatuhan yang tercatat: untuk entri direktori, alamat kepatuhannya atau kontak yang dapat dilihat aplikasi Anda dicontacts; untuk anggota jaringan Didit, email kepatuhan yang sudah dikonfirmasi. Jika dihilangkan, alamat yang digunakan adalah alamat tempat email Travel Rule ke pihak lawan dikirim: kontak Anda terlebih dahulu, lalu kontak platform, lalu alamat kepatuhan entri tersebut. Didit tidak pernah mengirim kuesioner ke tempat lain, dan mengembalikan400ketika pihak lawan tidak memiliki alamat kepatuhan yang tercatat. - Menjawab. Tautan membuka
/v3/travel-rule/questionnaires/{token}/, sebuah halaman untuk seseorang di pihak lawan yang tidak memerlukan akun maupun kunci API. Mereka menjawab setiap pertanyaan, hingga 2.000 karakter per pertanyaan (N/Ajika tidak berlaku), dan mengirimkannya satu kali. Pihak lawan juga dapat mengirim{"answers": {"<question id>": "<answer>"}}ke tautan yang sama. Tautan yang sudah digunakan, diganti, atau melewati tenggatnya akan menampilkan halaman kedaluwarsa. Email dan halaman diterjemahkan; pertanyaannya sendiri selalu dalam bahasa Inggris, sehingga maknanya tidak berubah antarbahasa. - Tenggat waktu. Pihak lawan memiliki 30 hari untuk menjawab (
expires_at). Jawaban tetap berlaku selama 365 hari (valid_until), dancurrentbernilaitruesampai saat itu. Kuesioner yang belum dijawab dan melewati tenggatnya, serta jawaban yang melewati masa berlakunya, menjadiEXPIRED. - Satu kuesioner terbuka per pihak lawan. Pengiriman baru menggantikan kuesioner Anda sebelumnya yang belum dijawab kepada pihak lawan yang sama: kuesioner itu menjadi
EXPIREDdan tautannya berhenti berfungsi. Satu email per menit dapat dikirim ke sebuah alamat; pengiriman yang lebih cepat mengembalikan429. - Membaca jawaban.
GET /v3/travel-rule/vasps/{vasp_id}/questionnaires/mencantumkan kuesioner Anda kepada pihak lawan, dari yang terbaru, dengananswersyang memiliki kunci berupa ID pertanyaan setelah dijawab. Direktori menampilkannya sebagaiquestionnaires. Data ini bersifat privat bagi aplikasi Anda.
1 berisi dua belas pertanyaan berikut:
Transfer dengan satu pihak lawan
GET /v3/travel-rule/transfers/?counterparty={vasp_id} menampilkan daftar transfer Travel Rule aplikasi Anda dengan satu pihak lawan, dari yang terbaru, berdasarkan id yang ditampilkan direktori: transfer Anda yang pihak lawannya adalah entri direktori tersebut, atau pertukaran INTERNAL Anda dengan anggota jaringan Didit tersebut. Nilai yang bukan id yang valid menghasilkan respons 400.
Setiap baris memuat reason tepat setelah status: reason milik transfer itu sendiri, sehingga daftar dapat membedakan email kepatuhan yang terpental dari pihak lawan yang tidak memiliki rute, tanpa membuka setiap transfer.
Kebijakan sunrise dan tidak responsif
Saat transfer kedaluwarsa (confirmation_timeout_hours terlewati ketika statusnya AWAITING_COUNTERPARTY), timeout_outcome menentukan apa yang terjadi pada transaksinya. Dua pengaturan memungkinkan Anda memperlakukan dua alasan umum timeout secara berbeda:
HOLD, REJECT, atau PROCEED, dengan arti yang sama seperti untuk timeout_outcome, atau string kosong untuk mengikuti timeout_outcome. Keduanya kosong secara default, sehingga tidak ada yang berubah sampai Anda mengatur salah satunya:
sunrise_policy, jika diatur dan yurisdiksi pihak lawan ada disunrise_jurisdictions.non_responsive_policy, jika diatur dan pihak lawan berstatusUNRESPONSIVE.timeout_outcomedalam kasus lainnya, termasuk transfer ke anggota jaringan Didit atau ke pihak lawan yang tidak memiliki entri direktori.
sunrise_jurisdictions bersifat hanya-baca dan saat ini berisi ["CO", "KH", "VN"]. Hanya negara-negara ini yang dianggap berada dalam periode sunrise: yurisdiksi lain, serta yurisdiksi yang kosong atau tidak dikenal, mengikuti timeout_outcome, sehingga pihak lawan tidak pernah menerima kebijakan sunrise Anda secara tidak sengaja. Linimasa transfer yang kedaluwarsa menyebutkan hasil yang berlaku, misalnya sunrise_policy=PROCEED (counterparty jurisdiction CO does not enforce the Travel Rule yet). Aturan Anda tetap berjalan setelah kedaluwarsa, sehingga aturan seperti EU TFR tr_eu_expired_review tetap dapat memindahkan transaksi ke peninjauan di bawah PROCEED.
Kolom aturan dan preset
Empat kolom aturan memuat informasi yang diketahui aplikasi Anda tentang pihak lawan yang dijangkau pertukaran Travel Rule suatu transaksi: entri direktorinya, atau untuk pertukaranINTERNAL, pelanggan Didit yang menerimanya. Setiap kolom kosong jika pertukaran tidak menjangkau pihak lawan yang dikenal.
travel_rule bekerja pada kolom-kolom tersebut. Pasang dari Transactions → Rules → Library di Business Console atau dengan API pustaka aturan:
Webhook
Daftarkan tujuan webhook ketravel_rule.status.updated untuk menerima notifikasi pada setiap transisi status dari setiap transfer di aplikasi Anda, baik keluar maupun masuk, termasuk leg INTERNAL-rail.
Perutean berjalan setelah pembuatan transaksi mengembalikan respons, sehingga hasil seperti COUNTERPARTY_VASP_NOT_FOUND, COUNTERPARTY_VASP_NOT_REACHABLE, atau pertukaran INTERNAL yang langsung diselesaikan sampai kepada Anda melalui event ini, bukan dalam respons pembuatan.
rail kosong sampai sebuah rail dipilih.
Untuk satu transaksi, Didit mengirim travel_rule.status.updated setelah transaction.created: ketika Didit membuat transaksi (POST /v3/transactions/ Anda, registrasi sunrise, permintaan TRP masuk, atau leg masuk INTERNAL-rail), Didit mengirim transaction.created terlebih dahulu.
Setiap event dikirim dan dicoba ulang secara terpisah, sehingga transaction.created yang perlu dicoba ulang tetap bisa tiba setelah event status. Gunakan transaction_id sebagai kunci handler Anda, dan baca transaksinya ketika event status menyebutkan transaksi yang belum pernah Anda lihat.
Transfer yang dikirim melalui TRUST tidak mendapatkan event COMPLETED: TRUST tidak mengirim balik apa pun yang dapat dibaca Didit, sehingga kecuali pengiriman gagal atau Anda membatalkannya, event terakhirnya adalah EXPIRED. Melalui GTR, VERIFYVASP, dan SYGNA, event mengikuti jawaban yang dibaca Didit dari jaringan.
Aplikasi sandbox juga mengirim event ini, dengan "environment": "sandbox"; transfer yang dijawab oleh Didit Test VASP membawa rail: "TEST_VASP", test_vasp: true, dan test_vasp_scenario.
Lihat panduan webhook untuk katalog event lengkap, verifikasi tanda tangan, dan kebijakan coba ulang.
Harga
Biaya Travel Rule adalah $0.02 per pertukaran keluar yang dimulai, dikenakan satu kali saat transaksi dibuat, terlepas dari berapa banyak transisi status yang dilalui pertukaran tersebut setelahnya.resend tidak pernah mengenakan biaya ini lagi.
- Berlaku untuk transaksi
travelRulekeluar pada aplikasi dengan Travel Rule aktif, yang jumlahnya sama dengan atau lebih besar darithreshold_amountAnda, sehingga Didit memulai pertukaran terkelola untuknya. Transfer ke dompet swakelola, atau ke dompet terverifikasi milik pengguna Anda, juga termasuk, karena bukti kepemilikan adalah pertukarannya. - Setiap transaksi keluar lain yang membawa data Travel Rule ditagih sebagai Skrining Transaksi standar, yang disertakan dalam paket Anda hingga batas transaksi bulanan dan dihargai $0.001 di atas batas tersebut: transfer di bawah ambang batas Anda, pembayaran Lightning yang tidak berlaku bagi Travel Rule, dan transfer yang dicatat secara pasif ketika Travel Rule nonaktif. Sebuah transaksi hanya ditagih pada salah satu dari dua baris, tidak pernah keduanya.
- Transaksi
travelRulemasuk tidak membawa biaya Travel Rule maupun biaya pemantauan: leg masuk yang Didit buat pada aplikasi penerima melaluiINTERNALrail, permintaanTRPmasuk, dan registrasi setelah deposit. - Aplikasi yang bergabung dengan Travel Rule secara gratis tidak membayar kedua biaya untuk transaksi
travelRulekeluar sampai Anda mengaktifkan penagihan keluar denganPOST /v3/travel-rule/workspace/billing/; menerima transfer tetap gratis. - Aplikasi sandbox tidak pernah dikenakan biaya.
- Biaya Travel Rule tercantum sebesar $0.02 dan Skrining Transaksi sebesar $0.001 di atas batas Anda. Setiap transaksi dikenakan harga dari baris yang ditagihnya.
- Jika skrining AML/Skrining Dompet juga berjalan pada transaksi yang sama (misalnya deposit masuk dengan
currency_kind: "crypto"dan pemantauan aktif), biaya tersebut ditagih terpisah dengan tarif standar Wallet Verification & Screening, dan tidak termasuk dalam biaya Travel Rule. - Skrining pihak lawan bersifat opsional dan ditagih terpisah, dengan harga Company AML Screening per skrining; skrining yang berusia kurang dari 30 hari digunakan kembali tanpa biaya. Keputusan, kuesioner, dan penilaian uji tuntas di direktori tidak dikenakan biaya.
Harga atribusi
Atribusi analitik blockchain memerlukan satu pencarian dompet ke penyedia analitik, dan Anda selalu mendapatkan nilai penuh dari pencarian tersebut:- Pemantauan kripto sudah memindai dompet pada transaksi ini - hasil yang tersimpan digunakan kembali. Satu panggilan analitik, satu biaya Wallet Verification & Screening (biaya yang sudah dikenakan oleh pemantauan kripto). Atribusi tidak menambah apa pun.
- Pemantauan kripto tidak berjalan - Didit melakukan panggilan analitik yang diperlukan sekali dan meneruskan nilai penuhnya: transaksi dikenakan tarif standar Wallet Verification & Screening ($0.15 dengan analitik yang dikelola Didit) dan menerima keluaran skrining kripto lengkap sebagai imbalannya, yaitu skor risiko, kategori risiko dompet, dan snapshot jaringan, bukan hanya nama VASP. Item penggunaan ditandai dengan pemicu
travel_rule_attributionagar biaya tersebut dapat dijelaskan. - Kunci analitik milik Anda sendiri - biaya platform yang sama yang berlaku untuk pemantauan kripto dengan kunci Anda sendiri juga berlaku di sini ($0.02 per panggilan). Penyedia Anda menagih pencarian yang mendasarinya langsung kepada Anda.
- Pencarian yang gagal tidak pernah dikenakan biaya, pengiriman ulang menggunakan kembali atribusi yang tercatat tanpa panggilan atau biaya baru, dan aplikasi sandbox tidak pernah dikenakan biaya.
Paket aturan EU TFR
Empat aturan preset disertakan dalam bundeltravel_rule_eu_tfr, yang dirancang khusus untuk kewajiban EU TFR.
Seperti setiap bundel preset lainnya, aktifkan dari Business Console di Transactions → Rules → Library.
Mengapa ini lebih baik di satu platform
Kepatuhan Travel Rule adalah masalah identitas yang menyamar sebagai masalah pembayaran, dan Didit sudah memiliki data identitasnya:- Data terverifikasi yang sudah tersedia. Subjek setiap transfer ditautkan melalui
vendor_datake profil KYC yang diverifikasi Didit saat onboarding (OCR dokumen, liveness, pencocokan wajah), sehingga Anda dapat membangunoriginator_datadari kolom yang sudah terverifikasi di platform yang sama. Untuk pengguna dengan verifikasi KYC yang disetujui, Didit mengirimkan identitas yang sudah terverifikasi, bukan nilai yang Anda ketik (lihat Data terverifikasi dan asal-usul data). - Biometrik tambahan untuk transfer berisiko. Aturan dapat menahan transfer bernilai tinggi apa pun sampai pengguna lolos pemeriksaan ulang biometrik terhadap wajah yang diambil saat onboarding. Ini adalah jawaban terkuat terhadap pengambilalihan akun pada saat penarikan dana. Lihat contoh kasus.
- Satu graf perangkat. Transfer yang dikirim melalui SDK membawa informasi perangkat yang sama seperti sesi KYC, sehingga “perangkat baru + jumlah besar + penerima baru” cukup menjadi satu aturan, tanpa perlu join data warehouse.
- Skrining, aturan, kasus, dan pertukaran di satu tempat. Skrining dompet yang mengidentifikasi VASP pihak lawan adalah skrining yang sama dengan yang dilihat aturan dan analis Anda, jadi cukup satu biaya, satu konsol, dan satu jejak audit.
- Harga yang dipublikasikan. $0.02 per pertukaran keluar, tanpa tingkatan berdasarkan volume, tanpa panggilan penjualan.
FAQ
Cara kerja pertukaran
Apakah Didit menjalankan pertukaran antar-VASP sendiri, atau hanya mencatat data Travel Rule setelah jaringan lain menyelesaikan jabat tangan?
Apakah Didit menjalankan pertukaran antar-VASP sendiri, atau hanya mencatat data Travel Rule setelah jaringan lain menyelesaikan jabat tangan?
travelRule, Didit melakukan penemuan pihak lawan secara langsung, mengirimkan data pengirim dan penerima ke VASP penerima melalui jalur yang membawanya, dan menandai transfer sebagai COMPLETED hanya setelah sisi pihak lawan mengonfirmasinya. Ini adalah jabat tangan terkelola, bukan log pasca-penyelesaian.
Jawaban dari pihak lawan diproses di setiap jalur kecuali TRUST, yang hanya mengirim, sehingga transfer melalui jalur tersebut akan kedaluwarsa, bukan selesai. Melalui GTR, VERIFYVASP, dan SYGNA, Didit membaca jawaban dari respons jaringan atau dengan melakukan polling setiap 5 menit, dan belum ada pertukaran melalui jalur tersebut yang selesai terhadap jaringan yang aktif. Melalui TRP, jawaban yang tidak langsung diberikan oleh pihak lawan memerlukan host TRP publik Didit, yang belum aktif (lihat Jaringan Travel Rule).
Didit juga menyimpan catatan lengkap dan status kepatuhan setiap pertukaran (sebuah siklus hidup dengan 13 status, webhook, dan jejak audit).
Jika Anda lebih suka menjalankan Travel Rule melalui proses Anda sendiri, Didit dapat mencatat data secara pasif sebagai sistem catatan utama Anda (lihat pertanyaan tentang pencatatan pasif di bawah).
Kedua mode tersedia: pertukaran aktif berjalan setelah Anda mengatur is_enabled: true di pengaturan (nilai default-nya false), dan sampai saat itu Didit mencatat data secara pasif.Apakah pertukaran ini asli dari Didit, atau bergantung pada penyedia interoperabilitas eksternal (Notabene, Sygna, VerifyVASP, TRP)?
Apakah pertukaran ini asli dari Didit, atau bergantung pada penyedia interoperabilitas eksternal (Notabene, Sygna, VerifyVASP, TRP)?
trp.didit.me setelah host publik tersebut aktif (saat ini belum merespons, sehingga pihak lawan belum dapat menjangkau Anda melalui TRP). Didit juga mengimplementasikan protokol jaringan industri secara langsung: GTR (Global Travel Rule), TRUST, VerifyVASP, dan Sygna Bridge (diimplementasikan secara langsung, termasuk IVMS 101 terenkripsi ECIES dari Sygna dan permintaan izin yang ditandatangani). Didit bukan reseller dari satu lapisan interoperabilitas pihak ketiga. Untuk menjangkau pihak lawan yang berada di jaringan keanggotaan tertentu, komunikasi tentu terjadi melalui jaringan tersebut, karena tidak ada satu saluran universal dalam Travel Rule. Namun penemuan, jabat tangan, verifikasi, dan pencatatan semuanya dijalankan oleh Didit.
Saat ini setiap jalur jaringan memerlukan keanggotaan Anda sendiri, dan TRUST hanya mengirim. Lihat Ikhtisar.Jaringan dan protokol Travel Rule apa saja yang didukung Didit?
Jaringan dan protokol Travel Rule apa saja yang didukung Didit?
INTERNAL (kedua VASP berada di Didit), TRP (OpenVASP Travel Rule Protocol), GTR, TRUST, VerifyVASP, Sygna Bridge, dan cadangan EMAIL untuk pihak lawan yang tidak memiliki alat pendukung.
Jalur jaringan memerlukan keanggotaan Anda sendiri saat ini, TRUST hanya mengirim, dan penerimaan melalui jaringan belum diaktifkan. Lihat Jaringan Travel Rule.
CODE, TRISA, Notabene, dan Veriscope muncul di Marketplace Didit sebagai kartu permintaan akses, tanpa integrasi saat ini.
Lihat Cara Didit merutekan pertukaran untuk tabel perutean lengkap, dan Jaringan Travel Rule untuk jangkauan setiap jaringan saat ini.Jaringan mana yang sebaiknya saya gunakan, dan apakah saya memerlukan keanggotaan sendiri?
Jaringan mana yang sebaiknya saya gunakan, dan apakah saya memerlukan keanggotaan sendiri?
TRP adalah dasar yang kami rekomendasikan: tidak memerlukan keanggotaan bersama. Dengan membagikan Travel Address Anda, VASP mana pun yang menggunakan TRP dapat menjangkau Anda. Ketika pihak lawan hanya diketahui melalui alamat, atribusi berbasis analisis blockchain hanya merutekannya melalui TRP jika entri direktori yang diatribusikan sudah memiliki endpoint TRP.
Untuk transaksi keluar, Didit mengirim aset yang tercantum di bawah Pengidentifikasi aset TRP melalui TRP. Pihak lawan yang tidak langsung merespons memerlukan host TRP publik Didit, yang belum aktif.
Untuk jaringan keanggotaan, pilih berdasarkan di mana pihak lawan Anda beroperasi: GTR menawarkan cakupan global yang luas, TRUST berorientasi pada VASP di AS, dan VerifyVASP (yang kini juga mengoperasikan Sygna Bridge) memiliki cakupan yang kuat di Asia.
Ya, saat ini Anda memerlukan keanggotaan sendiri: Didit belum memiliki keanggotaan platform di jaringan-jaringan ini dan sedang melakukan onboarding sebagai penyedia.
Hubungkan keanggotaan Anda di Marketplace; Anda tidak terikat pada satu jaringan saja.
Ingat bahwa TRUST hanya mengirim, sehingga transfer melalui jalur tersebut tidak akan selesai, dan belum ada pertukaran melalui jaringan apa pun yang selesai terhadap jaringan yang aktif.Bagaimana Didit menemukan VASP pihak lawan ketika saya hanya memiliki alamat?
Bagaimana Didit menemukan VASP pihak lawan ketika saya hanya memiliki alamat?
INTERNAL), buku alamat Anda sendiri untuk Travel Address yang tersimpan, lalu jalur protokol dan jaringan, dan terakhir atribusi berbasis analisis blockchain.
Jika transfer hanya membawa dompet tujuan, Didit mencocokkannya dengan data analisis blockchain untuk mengatribusikan bursa atau layanan kustodi pihak lawan, lalu mencatatnya di direktori VASP.
Transfer kemudian dirutekan secara otomatis hanya jika entri direktori tersebut sudah memiliki rute, seperti endpoint TRP. Jika tidak, transfer berakhir dengan COUNTERPARTY_VASP_NOT_FOUND dengan nama pihak lawan tercatat, dan Anda dapat mengirim ulang setelah rute tersedia, misalnya setelah Anda menyimpan travel_address pihak lawan pada entri buku alamat Anda untuk dompet tersebut (untuk aset yang tercantum di bawah Pengidentifikasi aset TRP).Harga dan lisensi
Berapa biaya Travel Rule, dan apakah sudah termasuk dalam paket KYC atau verifikasi saya?
Berapa biaya Travel Rule, dan apakah sudah termasuk dalam paket KYC atau verifikasi saya?
Apakah saya akan dikenakan tagihan ganda ketika Travel Rule dan pemantauan kripto berjalan bersamaan?
Apakah saya akan dikenakan tagihan ganda ketika Travel Rule dan pemantauan kripto berjalan bersamaan?
travelRule ditagih dalam satu baris: biaya Travel Rule ($0.02) ketika memulai pertukaran keluar, dan Skrining Transaksi standar selain itu. Pencarian analisis blockchain hanya ditagih sekali: jika pemantauan kripto sudah menyaring dompet tujuan pada transaksi tersebut, atribusi menggunakan kembali hasil tersimpan itu tanpa biaya tambahan.
Transfer masuk yang dibuat Didit di sisi penerima tidak pernah dikenai biaya Travel Rule.Apakah Didit dapat menyediakan dokumentasi atau pernyataan kapabilitas untuk perizinan VASP atau berkas untuk regulator saya?
Apakah Didit dapat menyediakan dokumentasi atau pernyataan kapabilitas untuk perizinan VASP atau berkas untuk regulator saya?
Operasional dan data
Apa yang terjadi pada transfer di bawah ambang batas saya?
Apa yang terjadi pada transfer di bawah ambang batas saya?
NOT_APPLICABLE: tidak ada rail yang dicoba dan tidak ada data identitas yang keluar dari Didit.
Transaksi ditagih sebagai Transaction Screening standar, bukan dengan biaya Travel Rule.
Didit membandingkan ambang batas dengan jumlah yang dikonversi ke mata uang default aplikasi Anda.
Jika Didit tidak dapat mengonversi jumlahnya, ambang batas tidak diterapkan dan transfer diproses untuk pertukaran.
EU TFR tidak memiliki batas minimum, sehingga CASP di UE sebaiknya mempertahankan threshold_amount pada 0.00.Bagaimana jika pihak lawan tidak pernah merespons?
Bagaimana jika pihak lawan tidak pernah merespons?
AWAITING_COUNTERPARTY hingga confirmation_timeout_hours berlalu, lalu sweeper memindahkannya ke EXPIRED dan menerapkan timeout_outcome Anda ke transaksi yang mendasarinya: HOLD untuk peninjauan, REJECT untuk menolak, atau PROCEED untuk membiarkannya tidak berubah. Aturan preset tr_eu_expired_review juga menampilkan setiap kedaluwarsa kepada analis Anda. Pihak lawan yang sama sekali tidak mengambil pesan tersebut merupakan kasus yang berbeda: Didit mencoba kembali, dan setelah percobaan gagal yang keenam, transfer dipindahkan ke COUNTERPARTY_VASP_NOT_REACHABLE (lihat Pengiriman dan coba lagi).Pihak lawan saya tidak memiliki alat Travel Rule sama sekali. Apakah saya tetap bisa mematuhi ketentuan?
Pihak lawan saya tidak memiliki alat Travel Rule sama sekali. Apakah saya tetap bisa mematuhi ketentuan?
EMAIL. Kontak kepatuhan mereka menerima tautan pengambilan satu kali dan dapat mengonfirmasi atau menolak pertukaran dari halaman yang di-hosting tanpa akun Didit, tanpa kunci API, dan tanpa integrasi. Untuk deposit yang sudah diselesaikan sebelum pertukaran apa pun dimungkinkan, gunakan pendaftaran sunrise setelah deposit.Bagaimana cara kerja penarikan ke dompet pengguna sendiri?
Bagaimana cara kerja penarikan ke dompet pengguna sendiri?
payment_method.method_type: "unhosted_wallet"). Didit melewati perutean VASP dan sebagai gantinya mengumpulkan bukti bahwa pelanggan Anda mengendalikan dompet tersebut, melalui penandatanganan pesan, tes Satoshi, tangkapan layar, atau pernyataan mandiri, melalui widget kepemilikan dompet. Itulah kewajiban EU TFR terkait dompet swakelola dalam bentuk API.Apakah data pribadi pihak lawan terlindungi selama pertukaran?
Apakah data pribadi pihak lawan terlindungi selama pertukaran?
GTR, TRUST, VERIFYVASP, SYGNA) juga mengenkripsi payload IVMS dengan kunci publik VASP penerima.Saya sudah melacak kepatuhan Travel Rule dengan proses saya sendiri. Bisakah saya langsung mencatatnya?
Saya sudah melacak kepatuhan Travel Rule dengan proses saya sendiri. Bisakah saya langsung mencatatnya?
travel_rule_details apa pun yang Anda kirimkan (termasuk status yang disediakan oleh pemanggil, baik yang berlaku saat ini maupun yang lama) dicatat secara pasif pada transaksi. Tidak ada rail yang dijalankan dan tidak ada yang dinegosiasikan. Gunakan ini untuk mengisi data historis atau menjalankan proses Anda sendiri sambil tetap menggunakan satu sistem pencatatan.Bagaimana cara menguji ini sebelum beroperasi penuh?
Bagaimana cara menguji ini sebelum beroperasi penuh?
transaction.created serta transaction.status.updated, dan setiap pertukaran keluar dikirim ke Didit Test VASP pada rail TEST_VASP, yang menjawab di dalam Didit dengan skenario yang Anda pilih: terima, tolak, ketidaksesuaian nama, tidak dapat dijangkau, waktu habis, atau dompet swakelola. Anda menerima webhook travel_rule.status.updated yang ditandai environment: sandbox, dan tidak ada pesan yang sampai ke pihak lawan sungguhan.
Untuk transfer masuk, minta VASP penguji mengirimkan transfer kepada Anda dengan Trigger Test VASP Inbound Transfer, atau daftarkan satu dengan POST /v3/travel-rule/inbound/. Keduanya diputuskan berdasarkan buku alamat dompet Anda: ON_HOLD, UNCONFIRMED_OWNERSHIP, COUNTERPARTY_MISMATCHED_DATA, atau COMPLETED lalu FINISHED.
Untuk pertukaran dua pihak dengan aplikasi sungguhan lain, gunakan dua aplikasi produksi milik Anda sendiri pada rail INTERNAL: aplikasi penerima harus dapat ditemukan dan harus membuktikan kendali atas dompet tujuan dengan pesan yang ditandatangani atau deposit uji.