Membangun Platform Exchange Crypto Enterprise: Business Logic, Fitur, dan Domain Knowledge

Di balik layar platform operasional exchange crypto: bagaimana sistem menghandle 500+ aset digital, memproses jutaan transaksi dengan reconciliation engine, menjalankan payment gateway multi-versi, menyaring wallet blockchain lewat AML provider, dan mengelola siklus hidup aset digital dari proposal hingga listing — semua sambil menjaga safeguarding compliance dan audit trail yang immutable.

Faisal Affan

7/25/2026

[!TIP] Semua yang ditulis di sini adalah sistem production yang berjalan di Google Cloud saat ini. Tidak ada yang fictive. Semua nama platform, modul, dan vendor eksternal adalah nama samaran.

Konteks: Ini Platform Apa?

Bayangkan Anda menjalankan sebuah cryptocurrency exchange. Setiap hari, ribuan user deposit dan withdraw crypto. Ratusan trade terjadi per detik. Anda wajib melaporkan semua aktivitas ini ke regulator, memastikan dana customer aman di vault yang tepat, dan menyaring setiap wallet dari risiko pencucian uang.

NEXCORE adalah platform yang melakukan semua itu. Ia bukan exchange-nya — ia sistem operasional di belakang exchange. Tiga business scope utama:

Mari kita bongkar business logic di balik setiap scope.

ASMOD: Bagaimana Sebuah Aset Crypto Bisa Listed di Exchange

Digital Asset Registry: Bukan Sekadar Tabel Crypto

ASMOD Digital Asset service menyimpan registry 500+ cryptocurrency. Tapi ini bukan sekadar database nama dan ticker. Setiap aset punya:

• Metadata lengkap: blockchain platform, smart contract address, decimals, network
• Price sources: mapping ke CoinGecko ID, CoinMarketCap UCID, atau sumber harga internal
• Lifecycle state: active, suspended, inactive — dengan kemampuan scheduled status change (misal: suspend otomatis tanggal X)
• Audit trail: setiap perubahan konfigurasi tercatat — siapa, kapan, apa yang berubah, kenapa

Kenapa scheduled status change penting? Karena kalau sebuah aset akan di-delist, exchange perlu waktu untuk mengumumkan ke user. Status change dijadwalkan di masa depan, bukan langsung dieksekusi.

Reference Pricing: Dari Mana Harga Berasal?

Setiap aset crypto butuh harga referensi untuk perhitungan compliance dan pelaporan. Harga diambil dari:

1. CoinGecko — provider utama, gratis dengan rate limit
2. CoinMarketCap — provider alternatif, dipakai jika CoinGecko tidak available
3. Internal trade data — untuk aset yang tidak terdaftar di provider eksternal, harga dihitung dari rata-rata trade terbaru

Scheduler berjalan periodik mengambil harga dari semua provider. Harga mentah disimpan sebagai raw_price_data. Lalu reference calculator menggabungkan semua sumber — prioritas berdasarkan konfigurasi source mapping per aset.

Ini bukan hal trivial. Bayangkan: 500 aset × 2 provider × update setiap 5 menit = 288.000 data points per hari. Semua harus konsisten dan auditable.

LISTGOV: Sistem Proposal dan Voting untuk Listing Aset Baru

LISTGOV adalah sistem governance untuk memutuskan aset crypto mana yang layak listing di exchange. Ini bukan sekadar form submission. Ini workflow lengkap:

1. Partner mengajukan proposal

Exchange partner mengisi form proposal yang mencakup:

• Data aset: nama, ticker, blockchain platform, smart contract address
• Data developer: nama tim, tipe developer (internal/eksternal)
• CoinMarketCap UCID dan CoinGecko ID (untuk verifikasi harga)
• Link website dan dokumen pendukung
• File attachment (whitepaper, audit report, legal opinion)

2. Board assessment

Setiap proposal masuk ke board yang sesuai (misal: Main Board untuk aset established, Fast Track untuk aset yang sudah listed di exchange besar). Board punya assessment questions — pertanyaan due diligence yang harus dijawab oleh tim internal:

• Apakah smart contract sudah di-audit?
• Bagaimana likuiditas di exchange lain?
• Apakah ada risiko regulasi di jurisdiction tertentu?
• Siapa di balik proyek ini? Track record mereka?

3. Voting

Setelah assessment lengkap, anggota board memberikan suara: approve atau reject, dengan alasan. Voting menentukan nasib proposal.

4. Keputusan final

• Approved → aset masuk ke registry, bisa langsung di-listing di exchange
• Rejected → proposal ditolak, partner bisa mengajukan ulang dengan data baru

Seluruh proses tercatat immutable — siapa yang vote apa, kapan, dengan alasan apa.

Trade Reporting: Mencatat Setiap Trade yang Terjadi

Setiap kali exchange mengeksekusi trade (spot), mereka wajib melaporkannya ke ASMOD Reporting. Data yang dilaporkan:

• Trade identity: trade_id, exchange_id, pair (misal: BTC/IDR)
• Maker & taker: siapa yang pasang order, siapa yang mengambil
• Harga & quantity: price, quantity, quote currency, notional value
• Fee breakdown: platform fee, tax, bourse fee — masing-masing dengan asset ID dan value
• Timestamp: kapan trade terjadi, kapan dilaporkan

Trade yang terlambat dilaporkan (melebihi threshold waktu) di-flag sebagai LATE atau SUPER_LATE. Compliance flags otomatis terpasang. Ini penting karena regulator melihat ketepatan waktu pelaporan.

Market Maker Program

Market maker adalah entitas yang menyediakan likuiditas di exchange. ASMOD Reporting mengelola registry market maker:

• Pendaftaran: nama, user ID, exchange ID, tipe, remarks
• Approval workflow: create → pending → approve/reject
• Status tracking: active, inactive
• Trade flagging: setiap trade dari market maker ditandai — sehingga bisa dibedakan dari trade regular dalam pelaporan

TXMOD: Transaksi, Rekonsiliasi, dan Koreksi

Transaction System: Bagaimana Sebuah Transaksi Diproses

Ini adalah core ledger. Setiap deposit dan withdrawal crypto/fiat dari exchange partner dicatat di sini. Yang membuatnya kompleks adalah business rules di balik pencatatan.

Submission Flow:

1. Exchange partner mengirim transaksi via API dengan request_id unik
2. System cek Redis: apakah request_id ini sudah pernah diproses? Jika ya, kembalikan response yang sama (idempotensi)
3. Validasi: apakah aset terdaftar di ASMOD Digital Asset? Apakah exchange dalam status aktif? Apakah amount > 0? Apakah transaction_time tidak lebih dari 15 menit yang lalu?
4. Jika DEPOSIT → langsung COMPLETED (tidak ada intermediate state). Jika WITHDRAWAL → masuk ke IN_PROGRESS dulu, menunggu konfirmasi
5. Balance entry dibuat otomatis: DEPOSIT = positive entry, WITHDRAWAL = negative entry

Status Transitions:

DEPOSIT:    DRAFT → COMPLETED
WITHDRAWAL: DRAFT → SUBMITTED → IN_PROGRESS → COMPLETED/FAILED

Kenapa WITHDRAWAL punya state IN_PROGRESS? Karena withdrawal butuh konfirmasi dari vault/custodian sebelum dana benar-benar keluar. Kalau vault menolak (misal: insufficient balance), transaksi jadi FAILED.

Yang terjadi saat status jadi FAILED dari IN_PROGRESS:

Sistem otomatis membuat reversal entry — offsetting entry yang membatalkan efek balance sebelumnya. Kalau tadinya WITHDRAWAL membuat negative entry, reversal membuat positive entry dengan jumlah yang sama. Bersih.

Safeguarding Compliance:

Ini adalah regulasi yang mewajibkan exchange menyimpan persentase tertentu dana customer di vault yang aman (bukan di hot wallet). Sistem menghitung:

• Customer balance: total dana customer per aset (dari balance entries)
• Custodied balance: total dana di vault yang tercatat (dari vault reports)
• Compliance ratio: custodied / customer balance

Konfigurasi threshold (misal 90%) menentukan apakah exchange compliant atau breach. Semua perhitungan dikonversi ke USD menggunakan reference price dari ASMOD Digital Asset — karena threshold dievaluasi dalam USD, bukan per-aset.

TOPUP dan REDEEM operations:

• TOPUP: menambah dana ke vault (meningkatkan custodied balance)
• REDEEM: menarik dana dari vault (menurunkan custodied balance)

Keduanya tercatat sebagai safeguarding_operations dengan audit trail lengkap.

Reconciliation Engine: Membandingkan Dua Sisi Buku

Setiap hari (atau periode tertentu), tim operasional harus memastikan bahwa dana customer yang tercatat di ledger (customer balance) cocok dengan dana yang benar-benar ada di vault (custodied balance). Ini yang disebut reconciliation.

Reconciliation bukan sekadar query SELECT SUM(balance) FROM customers lalu bandingkan. Ia melibatkan:

1. Multi-source data aggregation

Data diambil dari tiga sumber:

• Transaction system (TXMOD/CMMOD): semua balance entries untuk periode tersebut
• Vault API (Fireblocks): balance aktual di vault account
• Price feed (ASMOD Digital Asset): harga referensi untuk konversi USD

2. Net position calculation per aset

Untuk setiap aset, system menghitung:

• Net customer balance = SUM(semua positive entries) - SUM(semua negative entries) untuk exchange tersebut
• Net custodied balance = SUM(semua vault balance) dari Fireblocks

Perhitungan ini dilakukan per exchange, per aset, per balance type.

3. Compliance evaluation

Setelah perhitungan, system mengevaluasi:

• Apakah custodied ≥ threshold% × customer balance? (dalam USD)
• Aset mana yang breach?
• Berapa selisihnya?

Configurable percentage memungkinkan threshold berbeda untuk aset berbeda (misal: stablecoin 95%, volatile asset 80%).

4. Approval workflow

Hasil reconciliation tidak otomatis final. Ia masuk ke workflow:

• DRAFT: perhitungan awal, belum direview
• PENDING: sudah dihitung, menunggu approval
• APPROVED: disetujui oleh tim operasional
• REJECTED: ditolak, perlu dihitung ulang

Auto-approval scheduler menghandle routine reconciliation (misal: daily reconciliation yang hasilnya dalam batas normal).

5. Rebalancing

Kalau imbalance terdeteksi — misal vault A kelebihan BTC, vault B kekurangan BTC — system menyediakan rebalancing workflow. Tim operasional bisa menginisiasi transfer antar vault untuk menyeimbangkan.

6. Heavy computation via Cloud Run jobs

Full reconciliation untuk satu exchange besar bisa menyentuh jutaan baris transaksi. Ini bukan query yang bisa dijalankan di request-response HTTP biasa. System menggunakan Google Cloud Run jobs — container yang di-spawn khusus untuk menjalankan perhitungan, lalu mati sendiri setelah selesai.

Revision System: Mengoreksi Tanpa Menghancurkan

Bagaimana kalau exchange partner salah input transaksi? Misal: jumlah deposit seharusnya 1.5 BTC, tapi tercatat 15 BTC.

Jawabannya: jangan edit data original.

Revision system menerapkan append-only model:

• VOID: membuat offsetting entry yang membatalkan efek transaksi original. Kalau original-nya deposit +15 BTC, VOID membuat entry -15 BTC.
• REV (Revision): membuat corrected entry dengan nilai yang benar. Dalam contoh di atas, REV membuat entry +1.5 BTC.

Transaksi original tidak pernah di-UPDATE atau di-DELETE. Ia tetap ada, immutable. Yang berubah adalah net effect setelah VOID + REV diaplikasikan.

Workflow Revision:

1. Exchange partner submit revision request — pilih transaksi mana yang perlu dikoreksi, upload bukti pendukung (screenshot, statement, dll.)
2. Validator berjalan otomatis — cek apakah balance customer cukup untuk VOID? Apakah tidak ada revision lain yang sedang in-flight untuk transaksi yang sama?
3. Internal team review — bisa approve atau reject
4. Kalau approved, revision di-apply ke transaction system terkait (TXMOD, CMMOD, atau ASMOD Reporting — tergantung tipe transaksi)
5. Email notifikasi dikirim via n8n di setiap stage

Kenapa tidak edit langsung?

Karena audit trail. Regulator harus bisa melihat history lengkap: transaksi original yang salah, siapa yang mengoreksi, kapan, dengan alasan apa, dan bukti pendukungnya. Kalau data di-edit langsung, history hilang. Ini prinsip dasar financial systems: immutability of records.

Payment Gateway: Uang Fiat Masuk dan Keluar

TXMOD Payment Gateway adalah jembatan antara dunia crypto dan dunia fiat. Ia menghandle pembayaran via Xendit (payment gateway Indonesia).

Use case: user exchange ingin deposit Rupiah untuk membeli crypto, atau withdraw Rupiah hasil penjualan crypto.

Bagaimana cara kerjanya:

1. User membuat transaksi deposit/withdrawal fiat di exchange
2. Exchange mengirimkan instruksi payment ke Xendit (via API)
3. Xendit memproses pembayaran — bisa via Virtual Account, bank transfer, atau e-wallet
4. Ketika pembayaran selesai (atau gagal), Xendit mengirim webhook ke Payment Gateway
5. Payment Gateway memvalidasi webhook (signature check), mencatat event, lalu meneruskannya ke transaction system untuk update balance

Kompleksitas: Dual API Version

Xendit punya dua versi API yang berbeda struktur payload webhook-nya:

• V2 (Legacy): masih dipakai oleh beberapa exchange partner
• V3 (Current): payload terstruktur, signature-based

Payment Gateway harus menghandle keduanya. Setiap webhook masuk → validasi signature → tentukan apakah ini payment atau payout → tentukan versi API → parse payload sesuai struktur → catat ke database → proses.

Sender validation:

Sebelum pembayaran diproses, system memvalidasi nama pengirim. Apakah nama di rekening bank cocok dengan nama user di sistem? Fuzzy name matching digunakan karena format nama bisa berbeda (misal: "M Faisal Affan" vs "Muhammad Faisal Affan").

CMMOD: Compliance dan Akses Partner

Transaction API untuk Exchange Partner

CMMOD Transaction System menyediakan REST API yang digunakan langsung oleh exchange partner. Berbeda dengan TXMOD yang lebih ke internal operations.

Autentikasi HMAC:

Setiap request dari partner harus menyertakan:

• X-API-Key: API key unik per exchange
• X-Timestamp: timestamp epoch untuk mencegah replay attack
• X-Signature: HMAC-SHA256 dari (request body + timestamp) menggunakan API secret

Kalau ada yang tidak cocok, request langsung ditolak — sebelum menyentuh business logic.

Rate Limiting dan Idempotensi:

Setiap partner punya rate limit. Setiap transaksi punya request_id unik. Kalau network gagal dan partner retry, system tidak akan mencatat transaksi dua kali. Redis menyimpan mapping request_id → response dengan TTL 24 jam.

Business rules sama dengan TXMOD — validasi aset, validasi exchange, status transitions, balance entries, safeguarding compliance. Yang membedakan adalah target user: TXMOD untuk tim internal, CMMOD untuk exchange partner eksternal.

Blockchain Wallet Screening via Chainalysis

Ini adalah komponen AML (Anti-Money Laundering). Sebelum exchange partner memproses transaksi, mereka bisa (dan sebaiknya) menyaring wallet address-nya.

Workflow screening:

1. Staff exchange input wallet address + pilih blockchain network + coin
2. System kirim address ke Chainalysis API
3. Chainalysis mengembalikan risk assessment:
   • Risk score (0-100)
   • Sanctions list matches (apakah wallet terkait entitas yang di-sanksi?)
   • Exposure categories (darknet market, ransomware, stolen funds, dll.)
4. Hasil disimpan dan ditampilkan ke staff
5. Kalau risk score di atas threshold, transaksi dari wallet tersebut bisa di-block

Kenapa ini penting?

Karena exchange wajib comply dengan regulasi AML/KYC. Menerima dana dari wallet yang terkait aktivitas ilegal bisa berakibat serius — dari denda regulator sampai pencabutan izin operasi. Chainalysis screening adalah first line of defense.

Re-screening:

Wallet bisa di-screen ulang kapan saja. Risk assessment bukan one-time check — wallet yang bersih hari ini bisa jadi berbahaya besok (karena terlibat transaksi ilegal setelah screening pertama).

Bagaimana Semua Ini Terhubung

Semua service ini tidak berjalan sendiri-sendiri. Mereka membentuk sebuah workflow terintegrasi:

Exchange Partner
  │
  ├─→ CMMOD Transaction System (lapor transaksi)
  │     ├─→ ASMOD Digital Asset (validasi aset, cek harga)
  │     └─→ Redis (idempotensi)
  │
  ├─→ CMMOD Wallet Screening (Chainalysis AML check)
  │
  ├─→ ASMOD Reporting (lapor trade)
  │     └─→ ASMOD Digital Asset (harga referensi)
  │
  └─→ TXMOD Payment Gateway (deposit/withdraw fiat)
        └─→ Xendit (proses pembayaran)
              └─→ Webhook balik → TXMOD Payment Gateway
                    └─→ TXMOD Transaction System (update balance)

Internal Operations Team
  │
  ├─→ TXMOD Reconcile System (rekonsiliasi balance)
  │     ├─→ TXMOD Transaction System (data transaksi)
  │     ├─→ CMMOD Transaction System (data transaksi partner)
  │     ├─→ ASMOD Reporting (data trade)
  │     ├─→ ASMOD Digital Asset (harga USD)
  │     └─→ Fireblocks (vault balance aktual)
  │
  ├─→ TXMOD Revision System (koreksi transaksi)
  │     ├─→ TXMOD Transaction System (apply revision)
  │     ├─→ CMMOD Transaction System (apply revision)
  │     └─→ ASMOD Reporting (apply trade revision)
  │
  └─→ ASMOD Digital Asset (kelola aset, proposal, voting)
        ├─→ CoinGecko (harga)
        └─→ CoinMarketCap (harga alternatif)

Setiap panah di atas adalah API call yang harus reliable, memiliki retry logic, timeout yang tepat, dan error handling yang graceful.

Business Logic yang Paling Menarik

Dari semua yang sudah dijelaskan, ada beberapa pola business logic yang menurut saya paling menarik:

1. Idempotensi Bukan Afterthought

Di sistem fintech, idempotensi adalah requirement utama — bukan nice-to-have. Network failure, timeout, retry — semua adalah expected behavior. Tanpa idempotensi, satu transaksi bisa tercatat berkali-kali. Redis sebagai idempotency store adalah pattern yang sederhana tapi kritis.

2. Immutable Records

Data finansial tidak boleh di-edit langsung. Setiap koreksi adalah entry baru (VOID + REV), bukan UPDATE ke row existing. Ini pattern yang sama dengan double-entry accounting — setiap transaksi punya offsetting entry. Audit trail lengkap adalah non-negotiable.

3. Multi-Source Truth untuk Harga

Harga referensi untuk satu aset bisa datang dari CoinGecko, CoinMarketCap, atau internal trade data. System harus memutuskan sumber mana yang prioritas, kapan fallback, dan bagaimana menggabungkan multiple sources. Konfigurasi ini per aset — BTC mungkin pakai CoinGecko sebagai primary, sementara token baru mungkin hanya punya internal trade data.

4. Reconciliation adalah Compute-Heavy

Menghitung net position untuk jutaan transaksi bukan query database biasa. Ini adalah batch computation yang butuh dijalankan di container terpisah (Cloud Run job), dengan hasil yang disimpan untuk direview. Tidak ada yang real-time di sini.

5. Multi-Tenancy di Database Level

Setiap exchange hanya boleh melihat datanya sendiri. Ini bukan filter di application code — ini policy di database level (PostgreSQL Row-Level Security). Kalau developer lupa WHERE clause, database tetap menolak. Defense in depth.

6. Progressive Rollout dengan Feature Flags

25+ feature flags memungkinkan fitur di-deploy ke production dalam state disabled. Di-enable bertahap: development → staging → production (exchange tertentu dulu) → production (semua). Zero-downtime, zero-risk deployment.

Kesimpulan

Artikel ini berdasarkan pengalaman production nyata. Semua nama platform dan modul internal yang disebutkan adalah nama samaran. Semua angka dan detail bisnis akurat per Juli 2026.