03 — Fitur, Modul, Menu & Form (Blueprint Fungsional)

Benchmark terhadap: TurnKey Lender, nCino, Temenos, Ellie Mae / ICE Mortgage Technology, Oracle Banking Loan Origination, CRIF Indonesia, Ad-ins (PT Adicipta Inovasi Teknologi), CorSys, Indonesian Cloud, AlurKerja (PT Javan Cipta Solusi), RDS (PT Reycom Document Solusi), dan MARS-LOS (PT Marstech Global).

Dokumen ini mendefinisikan fitur, modul, menu, dan form dari OriginIQ LOS. Penomoran (mis. MD-01) menjadi referensi bagi menu & form di frontend.

A. Daftar Modul & Menu (Informasi Arsitektur / Peta Aplikasi)

MD-01 — Dasbor & Pipeline

MD-02 — Origination & Aplikasi Kredit

MD-03 — KYC, AML & Nasabah

MD-04 — Underwriting & Credit Scoring

MD-05 — Persetujuan & Workflow

MD-06 — Dokumen & Tanda Tangan Elektronik

MD-07 — Pencairan (Disbursement)

MD-08 — Kepatuhan, Pelaporan & Biro Kredit

MD-09 — Administrasi & Konfigurasi

MD-10 — Notifikasi & Layanan Nasabah

B. Kamus Form (Referensi Field Penting)

F-APP-01 — Pengajuan Kredit Baru

• Tipe nasabah: Perorangan / UKM / Korporasi
• Data pemohon: nama, NIK/KTP (scan), NPWP, tanggal lahir, alamat (provinsi/kota/kecamatan/ kelurahan/kode pos), status perkawinan, jumlah tanggungan, pendidikan
• Data kontak: HP, email, alamat domisili, lama tinggal, status tempat tinggal
• Data usaha/pekerjaan: jenis pekerjaan/usaha, bidang usaha (KBLI), lama bekerja, jabatan, penghasilan, penghasilan tambahan
• Data keuangan: rekening bank, pengeluaran bulanan, kewajiban lain
• Produk kredit: jenis (KPR/KMG/KMK/KI/multiguna), plafon, tenor, tujuan penggunaan, suku bunga, metode angsuran
• Jaminan: tipe agunan, nilai pasar, deskripsi
• Kelengkapan: daftar dokumen unggah

F-UW-02 — Hasil Biro Kredit (SLIK + Pefindo)

• SLIK OJK: status permintaan, tanggal respons, jumlah fasilitas, kolektibilitas per fasilitas (1–5), total eksposur, DPK aktif/macet, IDEKU/ID permintaan
• Pefindo IdScore: skor (250–900), grade risiko, alasan skor (reason codes), laporan kredit historis
• Ringkasan risiko gabungan: status lulus/hati-hati/tolak

F-UW-01 — Analisis Kredit

• Debt Service Ratio (DSR): perhitungan otomatis vs ambang
• Loan to Value (LTV): nilai agunan vs plafon
• Skor internal (scorecard) & skor biro; risk grade akhir
• Rekomendasi: APPROVE / REJECT / REVIEW + catatan analis
• Fasilitas usulan: plafon akhir, tenor, pricing

F-APR-01 — Persetujuan Berjenjang

• Detail pengajuan & hasil underwriting (read-only)
• Tindakan: Setuju / Tolak / Kembalikan (return) / Tunda (pending) + catatan wajib
• Tingkat persetujuan sesuai LKMK; notifikasi ke pemutus berikutnya

F-DOC-03 — Tanda Tangan Elektronik

• Daftar dokumen akad, status sign tiap pihak (pemohon, bank, saksi)
• Metode sign: TTE tersertifikasi (PSrE) / digital signature
• Log waktu tanda tangan & integritas (hash)

F-DIS-01 — Instruksi Pencairan

• Nomor pengajuan, nomor rekening tujuan, bank tujuan, nominal, tanggal efektif
• Metode: RTGS/Kliring/transfer internal; batch ID
• Status: draft → terkirim → sukses/gagal → rekonsiliasi

F-KYC-02 — Verifikasi Identitas (eKYC & Biometrik)

• Dukcapil: NIK, nama, nama ibu kandung, tempat/tanggal lahir, gender → status match/not-found
• Biometrik: face-match (selfie vs KTP, skor 0–1), liveness/anti-spoof (skor 0–1), flag spoof
• Hasil: PASSED / FAILED → KYC VERIFIED / REJECTED (kombinasi Dukcapil + biometrik)
• AML screening: daftar sanksi, PEP, daftar hitam internal → amlRisk LOW/MEDIUM/HIGH

F-PRD-01 — Daftar Produk Kredit

• Kode & nama produk; segmen (KONSUMTIF/PRODUKTIF/PERUMAHAN/MULTIGUNA); tujuan penggunaan
• Plafon min/maks, tenor min/maks, bunga dasar, biaya provisi, grace period
• Wajib agunan (secured/unsecured); deskripsi; status aktif/nonaktif (soft-delete)

F-UW-03 — Scorecard & Policy (Mesin Aturan Bisnis / BRE)

• Parameter cut-off: DSR maks, LTV maks, DSR hard-reject, skor Pefindo minimal, kolektibilitas SLIK maks, skor internal minimal
• Decision table (aturan): nama, fakta (DSR/LTV/Pefindo/SLIK_KOL), operator, ambang, aksi (REJECT/REVIEW/APPROVE), severity, prioritas, status aktif
• Rule tester: uji seluruh aturan aktif terhadap nilai fakta contoh

F-APR-04 — Distribusi Tugas (Routing)

• Antrean tugas (worklist): instance, nama tugas, skill, prioritas, assignee, SLA
• Strategi: round-robin / skill-based / load-based; distribusi otomatis
• Beban kerja analis (load + tugas aktif); penugasan ulang manual per tugas

F-DOC-04 — Template Dokumen (Pembuat Kontrak / Doc Gen)

• Jenis dokumen: Perjanjian Kredit, Surat Persetujuan Pemberian Kredit (SPK), Addendum, Surat Kuasa
• Variabel merge: nomor akad, produk, debitur (perorangan NIK / korporasi NIB + PIC), plafon, tenor, bunga, jaminan, tujuan penggunaan
• Jadwal angsuran (anuitas): periode, angsuran, pokok, bunga, sisa pokok
• Output: preview + unduh (produksi: DOCX templating Carbone/Aspose + clause library + versi)

F-ENR-01 — Data Alternatif (Enrichment)

• Consent nasabah (wajib UU PDP 27/2022) → tanpa consent = NEEDS_CONSENT
• Sumber data: telco, e-commerce, sosial, utilitas, fintech, pekerjaan, geolokasi
• Output: skor pengayaan (400–899), score band (THIN/FAIR/GOOD/STRONG), uplift kelayakan, rekomendasi, sinyal risiko/penguatan

F-FDS-01 — Deteksi Penipuan (FDS)

• Device fingerprint: OS, root/jailbreak, emulator, VPN, resolusi layar
• Velocity: aplikasi 24 jam/7 hari, perangkat 30 hari, jam pengajuan pertama
• Aturan terpicu (kode, deskripsi, severity, skor) → skor 0–100, risk level, decision PASS / REVIEW / BLOCK; admin aturan di /api/v1/fraud/rules

C. Matriks Fitur vs Benchmark Vendor

Catatan: matriks adalah generalisasi kemampuan produk (bukan klaim fitur pasti tiap vendor). Ad-ins dikenal kuat di multifinance/leasing; CRIF & CorSys kuat di perbankan & biro kredit; RDS kuat di document management/digital signature; AlurKerja kuat di workflow engine & case management.

D. Alur & Status Pengajuan (State Machine)

DRAFT → SUBMITTED → KYC_IN_PROGRESS → KYC_COMPLETED
      → UNDERWRITING → DECISION_PENDING (REVIEW) ──┐
      → APPROVED ──────────────────────────────────┤
      → REJECTED (terminal)                        │
APPROVED → DOCUMENT_PREPARING → DOCUMENT_SIGNED
      → DISBURSEMENT_PENDING → DISBURSED (terminal)
REVIEW → APPROVED / REJECTED (via approval workflow)

Aturan transisi status divalidasi oleh loan-service; setiap transisi dipublish ke Kafka dan dicatat ke audit trail.

10 — Gap Analysis Group Modul LOS & Modul Pintar (AI)

Hasil pemeriksaan aplikasi terhadap 6 Group Modul LOS + 6 Modul Pintar (AI) yang diminta, beserta status "sudah ada / sebagian / belum" dan apa yang ditambahkan pada pembaruan ini.

Pembaruan terbaru (penyempurnaan modul): 7 modul dilengkapi & disempurnakan — Alternatif Data (Enrichment), Deteksi Penipuan (FDS), Pembuat Kontrak (Doc Gen), Manajemen Produk, Distribusi Tugas (Routing), Mesin Aturan Bisnis (BRE), dan e-KYC & Biometrik. Rincian endpoint & perubahan tercantum di bawah.

1. Status Group Modul LOS (18 Modul)

Group 1 — Front-End & Onboarding (Interaksi Nasabah & Petugas)

Group 2 — Verifikasi & Pengayaan Data (Validasi Keaslian Data)

Group 3 — Analisis & Penilaian Risiko (Otak Keputusan Kredit)

Group 4 — Alur Kerja & Operasional (Manajemen Proses Internal)

Group 5 — Finalisasi & Pencairan (Tahap Akhir Kontrak)

Group 6 — Administrasi & Analitik (Manajemen & Evaluasi)

2. Status Modul Pintar (AI) — 6 Modul

Keenam modul pintar belum ada dan ditambahkan sekarang: (1) satu microservice baru risk-intelligence-service di backend, dan (2) menu interaktif "Modul Pintar (AI)" di frontend dengan simulasi deterministic yang mencerminkan perilaku produksi.

3. Spesifikasi Modul Pintar (Cara Kerja Konvensional → Sentuhan Pintar)

S1 — AI Credit Scoring & Predictive Modeling

• Konvensional: skor = rumus tambah-kurang dari data form + SLIK.
• Pintar: model ML (XGBoost / Random Forest) menganalisis ribuan fitur, menghasilkan Probability of Default (PD), mencakup unbanked/underbanked (alternatif data).
• Implementasi: risk-intelligence-service → POST /api/v1/ai/scoring mengembalikan pd, score (300–850), grade, reason codes bergaya SHAP + kontribusi fitur.
• Governance: model registry + versi + evaluasi bias + explainability (wajib transparansi OJK).

S2 — Intelligent Document Processing (IDP) dengan Gen-AI

• Konvensional: OCR biasa — gagal saat dokumen buram/miring.
• Pintar: Computer Vision + LLM memahami konteks: deteksi slip gaji editan Photoshop, deteksi KTP hasil jepretan layar (screen-recapture), dan pencocokan tanda tangan kontrak vs KTP.
• Implementasi: POST /api/v1/ai/idp → ocrConfidence, photoshopDetected, screenRecapture, signatureMatch, blurDetected, riskFlags.

S3 — Behavioral Analytics & Digital Footprint Profiling

• Konvensional: sistem hanya tahu data yang diketik nasabah.
• Pintar: analisis psikometri & jejak digital (dengan izin via SDK): kecepatan ketik (copy-paste KTP → indikasi bot/fraud), pola GPS, waktu pengajuan (jam 2 pagi berkorelasi risiko), riwayat aplikasi terpasang.
• Implementasi: POST /api/v1/ai/behavioral → typingSpeed, copyPasteDetected, gpsVariance, submissionHour, anomalyScore, riskLevel, signals.

S4 — Automated Dynamic Pricing Engine (Risk-Based Pricing)

• Konvensional: bunga & limit kaku/seragam.
• Pintar: Risk-Based Pricing personal dalam hitungan detik — low risk → limit lebih besar + bunga lebih murah; high risk → limit dikecilkan + bunga dinaikkan.
• Implementasi: POST /api/v1/ai/pricing (input PD/profil) → offeredRate, offeredLimit, tier, rationale.

S5 — Graph Analytics untuk Anti-Fraud & Sindikat Kredit

• Konvensional: hanya cek KTP/HP sudah terdaftar atau belum.
• Pintar: Graph Database (Neo4j) melacak hubungan tersembunyi & Fraud Ring: 5 nasabah berbeda mendaftar berdekatan, tempat kerja sama, nomor HP berurutan, device ID sama.
• Implementasi: POST /api/v1/ai/graph → fraudRingDetected, matchedMembers, sharedSignals, ringConfidence.

S6 — AI Conversational Assistant (Virtual Underwriter)

• Konvensional: analis menelepon manual untuk wawancara / minta dokumen ulang.
• Pintar: AI Voice/Text Bot (in-app / WhatsApp): wawancara awal, verifikasi data lewat percakapan alami, otomatis minta unggah ulang dokumen buram.
• Implementasi: POST /api/v1/ai/assistant → reply, intent, requestedDocuments.

4. Arsitektur yang Ditambahkan

... (service eksisting) ...
        │
        └── risk-intelligence-service  (baru, port 8087)
              • Modul Enrichment (Alternatif Data)      /api/v1/data/enrichment
              • Modul Enrichment (batch, konsumen NIK)  /api/v1/data/enrichment/batch
              • Modul FDS (Deteksi Penipuan)            /api/v1/fraud/score
              • Admin Aturan FDS (list/tambah/toggle)   /api/v1/fraud/rules
              • Modul AI Scoring (PD/ML)                /api/v1/ai/scoring
              • Modul IDP (Gen-AI)                      /api/v1/ai/idp
              • Modul Behavioral Analytics              /api/v1/ai/behavioral
              • Modul Dynamic Pricing                   /api/v1/ai/pricing
              • Modul Graph Anti-Fraud                  /api/v1/ai/graph
              • Modul Virtual Underwriter               /api/v1/ai/assistant

        document-service (diperluas)
              • Pembuat Kontrak (Doc Gen)               /api/v1/documents/generate-contract
              • Template/Clause Library                 /api/v1/documents/templates
              • Kalkulator Jadwal Angsuran              /api/v1/documents/amortization

        loan-service (diperluas)
              • Manajemen Produk (CRUD penuh)           /api/v1/products/**  (GET/{id}, PUT, PATCH, DELETE)
              • Distribusi Tugas (Routing)              /api/v1/routing/**   (analysts, queue, workload, distribute, assign)

        customer-service (diperluas)
              • eKYC (Dukcapil + biometrik)             /api/v1/customers/{id}/kyc
              • Biometrik (face-match + liveness)       /api/v1/customers/{id}/biometric

Semua modul AI & biometrik memakai simulasi deterministic (seed dari NIK) agar bisa dijalankan tanpa kredensial produksi. Di produksi, ganti dengan model & integrasi sungguhan (ML, LLM, Neo4j, Dukcapil, vendor biometrik, dsb.) — lihat docs/09 untuk rekomendasi engine & lisensi.

13 — Alur Kerja & Alur Data Perbankan (Login → Logout)

Panduan ini menjelaskan alur kerja (workflow) pemakai sistem dan alur data (data flow) antarsistem OriginIQ LOS secara menyeluruh — dari proses login hingga logout — termasuk fase origination, verifikasi, penilaian risiko, persetujuan, kontrak, dan pencairan. Pemetaan didasarkan pada implementasi aktual: frontend SPA (menu & state machine) dan microservices backend (service-registry → api-gateway → auth/customer/loan/credit/ document/notification/risk-intelligence).

1. Aktor & Peran (RBAC)

Catatan: kontrol akses per-peran saat ini direpresentasikan pada level menu/UI (frontend) dan enforced di gateway (JWT + header X-User-Role) untuk produksi. Detail RBAC ada di docs/11 (Audit Keamanan).

2. Ringkasan Alur Kerja End-to-End

┌─────────┐   ┌──────────────┐   ┌──────────┐   ┌──────────────┐   ┌─────────────┐
│  LOGIN  │──▶│   DASBOR      │──▶│ ORIGINASI│──▶│  VERIFIKASI  │──▶│ PENILAIAN   │
│ (auth)  │   │  (pipeline)   │   │ (pengajuan)│  │  (eKYC+biro) │   │ (skoring)   │
└─────────┘   └──────────────┘   └──────────┘   └──────────────┘   └─────────────┘
                                                                    │ BRE / FDS
                                                                    ▼
┌──────────┐   ┌────────────┐   ┌─────────────┐   ┌──────────────┐   ┌─────────────┐
│  LOGOUT  │◀──│  ANALITIK  │◀──│  PENCAIRAN  │◀──│  KONTRAK +   │◀──│  PERSETUJUAN│
│ (token)  │   │ + LAPORAN  │   │(disbursement)│  │   e-SIGN     │   │ (berjenjang) │
└──────────┘   └────────────┘   └─────────────┘   └──────────────┘   └─────────────┘

Setiap langkah dicatat ke audit trail (siapa, apa, kapan) dan state pengajuan berpindah mengikuti state machine (lihat §5).

3. Alur Kerja Per Fase (Langkah demi Langkah)

Fase 0 — Login & Otentikasi

Catatan keamanan: password tidak pernah disimpan plaintext (bcrypt); token kedaluwarsa 15 menit; produksi disarankan OIDC/Keycloak + refresh token + revocation list (lihat §7).

Fase 1 — Dasbor & Pipeline

• Aktor melihat KPI (pengajuan hari ini, approval rate, antrean putusan, rata-rata plafon), grafik volume 14 hari, dan distribusi pipeline.
• Menu: #/dashboard, #/pipeline.

Fase 2 — Origination (Registrasi Nasabah → Pengajuan)

Fase 3 — Verifikasi & Pengayaan Data

Fase 4 — Penilaian Risiko (Underwriting & BRE)

Fase 5 — Persetujuan Berjenjang (LKMK / 4-eyes)

Fase 6 — Kontrak & Tanda Tangan Elektronik

Fase 7 — Pencairan (Disbursement)

Fase 8 — Analitik, Pelaporan & Audit

• Report Studio (#/reports): designer + viewer + ekspor CSV.
• Audit Trail (#/audit): semua perubahan & keputusan (immutable log).
• Pelaporan regulator (SLIK bulanan, LBU) — #/bureau "Kirim Laporan".

Fase 9 — Logout

JWT bersifat stateless — "logout" di sisi klien cukup membuang token. Untuk standar perbankan, tambahkan token revocation (refresh-token rotation) atau session di Redis agar logout benar-benar mematikan sesi server.

4. Alur Data (Data Flow) Antar Microservice

4.1 Peta Layanan & Port

Infrastruktur bersama: Kafka (event antar-layanan), Redis (cache/session/rate-limit), MinIO (object storage dokumen).

4.2 Alur Data Login (Otentikasi)

Browser (SPA)          API Gateway               auth-service              authdb
    │                      │                          │                       │
    │ POST /auth/login     │                          │                       │
    │─────────────────────▶│ (open path)              │                       │
    │                      │─────────────────────────▶│ cek rate limiter      │
    │                      │                          │ find user + bcrypt    │
    │                      │                          │───────────▶ (SELECT)  │
    │                      │                          │◀─────────── user      │
    │                      │                          │ issue JWT (HS256)     │
    │ 200 {accessToken,    │◀─────────────────────────│                       │
    │      profile}        │                          │                       │
    │◀─────────────────────│                          │                       │
    │ simpan token         │                          │                       │

4.3 Alur Data Setiap Request (Setelah Login)

Browser ──HTTP + Authorization: Bearer <JWT>──▶ api-gateway
                                                  │ AuthGlobalFilter:
                                                  │  • OPTIONS → lolos (CORS preflight)
                                                  │  • open path → lolos
                                                  │  • verify signature + exp
                                                  │  • inject X-User-Id / X-User-Name / X-User-Role
                                                  ▼
                                    route ke layanan via Eureka (lb://)
                                                  │
                     ┌────────────────┬───────────┼───────────────┬────────────┐
                     ▼                ▼           ▼               ▼            ▼
               customer-service   loan-service credit-service  document-svc  risk-intelligence
                     │                │           │               │            │
                     ▼                ▼           ▼               ▼            ▼
                 customerdb        loandb      creditdb       documentdb   (model/AI)

4.4 Alur Data Origination Kredit (End-to-End)

[1] Registrasi nasabah      Browser ──▶ gateway ──▶ customer-service ──▶ customerdb
[2] eKYC Dukcapil           customer-service ──▶ Dukcapil (eksternal) + biometrik vendor
[3] Buat pengajuan          Browser ──▶ loan-service ──▶ loandb (loan_application)
[4] Underwriting            loan-service ──▶ credit-service (DecisionEngine)
                              credit-service ──▶ SLIK OJK (eksternal, mock di dev)
                              credit-service ──▶ Pefindo IdScore (eksternal/REST adapter)
                              risk-intelligence ──▶ enrichment + FDS (feed skor)
[5] Simpan evaluasi         credit-service ──▶ creditdb (credit_evaluation)
[6] Putusan                 loan-service ──▶ loandb (approval_task, status)
[7] Generate kontrak        document-service ──▶ contract template (DOCX) ──▶ MinIO
[8] e-Sign                  document-service ──▶ PSrE (TTE tersertifikasi)
[9] Pencairan               loan-service ──▶ status DISBURSED ──▶ notification-service
[10] Audit                  setiap service ──▶ Kafka (event) ──▶ audit trail / report

4.5 Data di Setiap Tahap (At Rest)

4.6 Diagram Urutan (Sequence Diagram) per Fase

Notasi: panah solid ──▶ = request/response sinkron (HTTP); panah putus-putus ···▶ = event asinkron (Kafka) / notifikasi. Aktor luar sistem (Dukcapil, biro kredit, PSrE, core banking) berada paling kanan. Versi interaktif: kedelapan diagram di bawah tersedia sebagai diagram Mermaid.js yang dirender di browser di situs marketing OriginIQ (OriginIQ_web_marketing.html, bagian #diagrams) — Mermaid di-vendor lokal tanpa CDN.

Fase 0 — Login

Petugas      Frontend (SPA)      api-gateway        auth-service             authdb
   │            │                    │                   │                     │
   │ isi user+  │                    │                   │                     │
   │ password   │                    │                   │                     │
   │───────────▶│ POST /auth/login   │                   │                     │
   │            │───────────────────▶│  (open path)      │                     │
   │            │                    │──────────────────▶│ cek rate limiter    │
   │            │                    │                   │─SELECT user────────▶│
   │            │                    │                   │◀─────baris user─────│
   │            │                    │                   │ bcrypt.matches      │
   │            │                    │                   │ issue JWT (HS256)   │
   │            │                    │◀──200 {token, profil}────────────────────│
   │            │◀───────────────────│                   │                     │
   │◀─ simpan   │                    │                   │                     │
   │   token    │                    │                   │                     │

Fase 1 — Dasbor & Pipeline

Mode demo menghitung KPI di sisi klien dari store.applications; di produksi agregat dihitung di loan-service (SQL aggregate) lalu di-cache Redis — lihat §6.

Semua peran   Frontend (SPA)      api-gateway       loan-service        loandb
   │               │                   │                 │                 │
   │ buka #/dashboard                 │                 │                 │
   │──────────────▶│ GET /loans/aggregate              │                 │
   │               │──────────────────▶│ (JWT verify)  │                 │
   │               │                   │──────────────▶│─SELECT SUM/COUNT▶│
   │               │                   │               │◀──KPI + volume───│
   │               │◀──200 {kpi, distribusi status}────│  (14 hari)      │
   │◀─render KPI + │                   │               │                 │
   │  grafik 14 hr │                   │               │                 │
   │ buka #/pipeline                  │               │                 │
   │──────────────▶│ GET /loans?groupBy=status         │                 │
   │               │──────────────────▶│──────────────▶│─SELECT by status▶│
   │               │◀──200 kanban──────│◀──────────────│                 │
   │◀─kanban per   │                   │               │                 │
   │  status       │                   │               │                 │

Fase 2 — Origination (Nasabah → Pengajuan)

LOAN_OFFICER    Frontend        gateway       customer-service   customerdb    loan-service   loandb
   │              │                │                │                 │               │          │
   │ buat nasabah │                │                │                 │               │          │
   │─────────────▶│ POST /customers│                │                 │               │          │
   │              │───────────────▶│───────────────▶│ validasi NIK/   │               │          │
   │              │                │                │ NPWP/NIB/email  │               │          │
   │              │                │                │─INSERT─────────▶│               │          │
   │              │                │                │◀───nasabah──────│               │          │
   │              │◀──200 cust─────│◀───────────────│                 │               │          │
   │              │                │                │                 │               │          │
   │ buat pengajuan               │                │                 │               │          │
   │─────────────▶│ POST /loans    │                │                 │               │          │
   │              │───────────────▶│──────────────────────────────────────────────────▶│          │
   │              │                │                │                 │               │─INSERT──▶│
   │              │◀──200 app──────│◀──────────────────────────────────────────────────────────────│

Fase 3 — Verifikasi (eKYC + Biro Kredit)

UNDERWRITER   Frontend      gateway     customer-service   Dukcapil   Biometrik   credit-service   SLIK   Pefindo
   │            │              │              │               │            │             │          │      │
   │ eKYC       │              │              │               │            │             │          │      │
   │───────────▶│ POST /customers/{id}/kyc    │               │            │             │          │      │
   │            │─────────────▶│─────────────▶│─verify(NIK)──▶│            │             │          │      │
   │            │              │              │◀─{match}──────│            │             │          │      │
   │            │              │              │─face+liveness──────────────▶│             │          │      │
   │            │              │              │◀─{passed}───────────────────│             │          │      │
   │            │              │              │ kycStatus = VERIFIED/REJECTED│             │          │      │
   │            │              │              │   ···▶ event KYC_COMPLETED → Kafka            │          │      │
   │            │              │              │               │            │             │          │      │
   │ cek SLIK   │ POST /credit/bureau/slik    │               │            │             │          │      │
   │───────────▶│─────────────▶│─────────────────────────────────────────────────────────────▶│          │      │
   │            │              │              │               │            │             │──inquiry─▶│      │
   │            │              │              │               │            │             │◀─{fasilitas}│      │
   │            │              │              │               │            │             │          │      │
   │ cek Pefindo│ POST /credit/bureau/pefindo/score                                          │          │      │
   │───────────▶│─────────────▶│─────────────────────────────────────────────────────────────▶│──inquiry────────▶│
   │            │              │              │               │            │             │◀───{skor 250-900}──│

Fase 4 — Underwriting & Keputusan (BRE)

UNDERWRITER   Frontend      gateway      loan-service    credit-service      risk-intelligence    creditdb
   │            │              │               │                │                     │                │
   │ input penghasilan+        │               │                │                     │                │
   │ kewajiban   │              │               │                │                     │                │
   │───────────▶│ POST /loans/{id}/underwrite  │                │                     │                │
   │            │─────────────▶│──────────────▶│                │                     │                │
   │            │              │               │─evaluate()────▶│                     │                │
   │            │              │               │                │─hitung DSR/LTV + skor│                │
   │            │              │               │                │─ambil SLIK + Pefindo │                │
   │            │              │               │                │─cek aturan BRE (cut-off)│             │                │
   │            │              │               │                │───(opsional) enrichment + FDS──▶│               │
   │            │              │               │                │─INSERT credit_evaluation──────────────────────▶│
   │            │              │               │◀─{APPROVE/REJECT/REVIEW}─────────────────────────────────────────│
   │            │              │               │ set status pengajuan                                     │
   │            │◀──200 hasil──│◀──────────────│                │                     │                │

Fase 5–7 — Persetujuan → Kontrak → Pencairan

APPROVER   Frontend      gateway     loan-service     document-service   PSrE        core-banking
   │          │             │             │                 │              │               │
   │ putus   │ POST /loans/{id}/decision  │                 │              │               │
   │────────▶│────────────▶│────────────▶│─INSERT approval_task │           │               │
   │          │             │             │ status APPROVED/REJECTED         │               │
   │          │             │             │  ···▶ event APPROVED → Kafka                    │
   │          │             │             │                 │              │               │
   │ gen kontrak│ POST /documents/generate-contract │        │              │               │
   │────────▶│────────────▶│────────────────────────▶│─merge template + jadwal angsuran     │
   │          │             │             │                 │─simpan DOCX → MinIO             │
   │ e-Sign  │ POST /documents/{id}/sign   │                 │              │               │
   │────────▶│────────────▶│────────────────────────▶│─TTE (hash + timestamp)─▶│               │
   │          │             │             │                 │◀─tersertifikasi──│               │
   │          │             │             │ status DOCUMENT_SIGNED           │               │
   │          │             │             │  ···▶ event SIGNED → Kafka                       │
   │ cair    │ POST /loans/{id}/disburse   │                 │              │               │
   │────────▶│────────────▶│────────────▶│ status DISBURSED │              │──▶ transfer    │
   │          │             │             │  ···▶ notifikasi (email/SMS/push)               │

Fase 8 — Analitik, Pelaporan & Audit

COMPLIANCE    Frontend       gateway      loan-service     loandb     credit-service   SLIK OJK
   │             │              │             │              │             │             │
   │ buka #/reports (Report Studio)          │              │             │             │
   │────────────▶│ GET /reports/aggregate    │              │             │             │
   │             │─────────────▶│───────────▶│─SELECT agregat/group-by─▶│            │
   │             │              │            │◀──rows───────│             │             │
   │             │◀──200 tabel/CSV───────────│              │             │             │
   │ buka #/audit│              │            │              │             │             │
   │────────────▶│ GET /audit/trail          │              │             │             │
   │             │─────────────▶│───────────▶│◀──event log (immutable, dari Kafka)───────│
   │             │◀──200 jejak audit─────────│              │             │             │
   │ kirim laporan SLIK bulanan             │              │             │             │
   │────────────▶│ POST /credit/bureau/slik/report         │             │             │
   │             │─────────────▶│────────────────────────────────────────▶│             │
   │             │              │            │              │             │─kirim LKPB──▶│
   │             │              │            │              │             │◀─ack ID──────│
   │             │◀──200 {reportId}────────────────────────────────────────│             │

Fase 9 — Logout

Petugas      Frontend (SPA)      api-gateway         auth-service
   │              │                   │                   │
   │ klik "Keluar"│                   │                   │
   │─────────────▶│ hapus token +     │                   │
   │              │ state.user = null │                   │
   │              │ location.hash = "" (layar login)     │
   │              │  ···▶ (produksi) POST /auth/logout   │
   │              │                   │──────────────────▶│ simpan ke revocation list
   │              │                   │◀──202─────────────│
   │◀─layar login │                   │                   │

5. State Machine Pengajuan (Referensi)

DRAFT → SUBMITTED → KYC_IN_PROGRESS → KYC_COMPLETED
      → UNDERWRITING → DECISION_PENDING (REVIEW) ──┐
      → APPROVED ──────────────────────────────────┤
      → REJECTED (terminal)                        │
APPROVED → DOCUMENT_PREPARING → DOCUMENT_SIGNED
      → DISBURSEMENT_PENDING → DISBURSED (terminal)
REVIEW → APPROVED / REJECTED (via approval workflow)

Transisi divalidasi oleh loan-service; setiap transisi dipublish ke Kafka dan dicatat ke audit trail (lihat docs/03 bagian D).

Versi interaktif: diagram state machine ini, plus flowchart keputusan otomatis (BRE) dan flowchart persetujuan berjenjang (LKMK / 4-eyes), dirender interaktif dengan Mermaid.js di situs marketing OriginIQ (OriginIQ_web_marketing.html, bagian #diagrams grup "Pipeline & State Machine").

6. Matriks "Siapa Melakukan Apa" (Menu → Layanan → Data)

7. Penguatan Keamanan di Setiap Tahap (standar perbankan)

8. Kesimpulan

Alur kerja OriginIQ LOS dari login hingga logout membentuk satu siklus penuh origination kredit: otentikasi → registrasi → verifikasi (eKYC + biro kredit + data alternatif + FDS) → penilaian risiko (scoring + BRE) → persetujuan berjenjang → kontrak & e-sign → pencairan → pelaporan/audit → logout. Sepanjang alur, data mengalir antar-microservice melalui api-gateway (JWT) dan event Kafka, tersimpan di database per-layanan, dan setiap langkah tercatat di audit trail.

14 — Runbook Operasional (Produksi)

Runbook ini melengkapi docs/07 (menjalankan di development). Di sini dibahas operasi harian produksi OriginIQ LOS: urutan start/stop, backup & restore, disaster recovery, monitoring & alerting, penanganan insiden, keamanan operasional, dan runbook per layanan. Target SLA mengikuti docs/04: availability 99,95%, RPO < 15 menit, RTO < 1 jam, p95 latensi read < 300 ms / write < 500 ms. Kepatuhan mengikuti docs/05 (DRC & BCP wajib diuji).

1. Cakupan & Peran Operasional

1.1 Layanan yang dioperasikan

Infrastruktur bersama: PostgreSQL 16, Redis 7 (AOF), Kafka 3.7 (KRaft), MinIO. Sumber: infra/docker-compose.yml.

1.2 Matriks tanggung jawab (RACI singkat)

R = Responsible, A = Accountable, C = Consulted, I = Informed.

2. Startup & Shutdown (Urutan Wajib)

2.1 Startup (cold start / pemulihan penuh)

Urutan penting: infrastruktur → registry → gateway → services. Jangan start service sebelum registry & database siap.

# 1) Infrastruktur
cd infra && docker compose up -d
docker compose ps            # pastikan postgres/redis/kafka/minio "healthy"

# 2) Service registry (Eureka)
mvn -pl service-registry spring-boot:run    # tunggu "Started" + /actuator/health UP

# 3) API gateway
mvn -pl api-gateway spring-boot:run

# 4) Services (paralel, setelah registry UP)
mvn -pl auth-service spring-boot:run &
mvn -pl customer-service spring-boot:run &
mvn -pl loan-service spring-boot:run &
mvn -pl credit-service spring-boot:run &
mvn -pl document-service spring-boot:run &
mvn -pl notification-service spring-boot:run &

Verifikasi startup — seluruh health harus UP:

curl -s http://localhost:8080/actuator/health | jq .status          # gateway
curl -s -X POST http://localhost:8080/api/v1/auth/login -H 'Content-Type: application/json' \
  -d '{"username":"admin","password":"<secret>"}' | jq .accessToken # login end-to-end

2.2 Shutdown (graceful)

Urutan kebalikan: services → gateway → registry → infrastruktur.

1. Hentikan dulu entry point (gateway) agar tidak ada request baru masuk. 2. Hentikan services (beri grace period agar request in-flight selesai; Spring Boot server.shutdown=graceful + timeout-per-shutdown-phase=30s direkomendasikan). 3. Terakhir hentikan registry & infrastruktur. Jangan matikan PostgreSQL/Kafka/MinIO mendahului services — berisiko transaksi terputus / data loss.

# produksi (K8s): scale down ingress → deployments (graceful) → stateful infra terakhir
kubectl scale deployment api-gateway --replicas=0
kubectl scale deployment auth-service customer-service loan-service \
  credit-service document-service notification-service --replicas=0
# infra (postgres/kafka/redis/minio) tetap jalan sampai maintenance window selesai

3. Backup & Restore

3.1 Apa yang wajib di-backup

3.2 Backup PostgreSQL (contoh)

# dump logika harian per database (database-per-service)
for db in authdb customerdb loandb creditdb documentdb notificationdb; do
  docker exec originiq-postgres pg_dump -U originiq -Fc "$db" > "/backup/${db}_$(date +%F).dump"
done

# produksi: aktifkan archive_mode=on + pg_basebackup untuk PITR (point-in-time recovery)
# retensi WAL minimal 2x interval backup penuh

3.3 Backup MinIO (contoh)

mc alias set prod http://minio:9000 <access-key> <secret-key>
mc mirror --watch prod/loan-documents /backup/minio/loan-documents

3.4 Restore (langkah + verifikasi)

# 1) buat DB kosong & restore dump
docker exec originiq-postgres createdb -U originiq authdb_restore
docker exec -i originiq-postgres pg_restore -U originiq -d authdb_restore < /backup/authdb_2026-09-05.dump

# 2) restore MinIO (bucket dokumen)
mc mirror /backup/minio/loan-documents prod/loan-documents

# 3) verifikasi integritas
docker exec originiq-postgres psql -U originiq -d authdb_restore -c "SELECT count(*) FROM app_user;"
docker exec originiq-postgres psql -U originiq -d loandb_restore -c "SELECT count(*) FROM loan_application;"

Aturan emas: backup belum dianggap ada sampai restore-nya teruji. Jadwalkan restore drill bulanan (lihat §7 checklist). Target sesuai docs/04: RPO < 15 menit (WAL kontinu), RTO < 1 jam (prosedur di bawah).

4. Disaster Recovery & BCP (RPO < 15 mnt, RTO < 1 jam)

4.1 Topologi DR (active–passive, dua site)

SITE A (primary)                          SITE B (DR)
───────────────                           ───────────────
api-gateway (multi replica)               standby (scaled-down, otomatis naik saat failover)
services (multi replica)                  services (replica min 1)
PostgreSQL primary  ──streaming/WAL──▶    PostgreSQL standby (synchronous/async)
MinIO              ──site replication──▶  MinIO (replication bucket)
Kafka (3 broker)   ──MirrorMaker 2──▶    Kafka (3 broker)
Redis AOF                                  Redis AOF (replikasi)

4.2 Prosedur failover (ringkas)

4.3 Data loss & rollback

• Kehilangan data DB: restore PITR ke titik sebelum insiden (WAL), lalu re-run event dari Kafka (outbox) agar state konsisten.
• Dokumen hilang: restore bucket MinIO dari replika site.
• Konfigurasi salah: rollback deploy (lihat §8.2) + restore secret dari Vault (versioned).

5. Monitoring & Alerting

5.1 Endpoint kesehatan

Saat ini exposure terbatas (health,info,gateway) dan metrics/prometheus tidak diekspos di port publik (lihat komentar application.yml tiap service). Untuk produksi, scrape metrik lewat port manajemen terpisah — lihat docs/05.

5.2 Metrik kunci & ambang alert (usulan)

Alert diarahkan ke PagerDuty/Opsgenie dengan on-call rotation dan severity (SEV1…SEV4).

5.3 Stack observability (produksi, dari docs/04)

Prometheus (metrik) + Grafana (dash) + Loki (log) + Tempo (trace) — dedicated, terpisah dari workload, dengan retention log minimal 90 hari (kebutuhan audit perbankan).

6. Penanganan Insiden (Incident Response)

6.1 Severity

6.2 Alur standar

1. Deteksi (alert / laporan user) → buka tiket & kanal insiden. 2. Triage → tentukan severity & pemilik. 3. Mitigasi (stop bleeding): blokir, rollback, scale-up, failover — sebelum root cause. 4. Root cause analysis (RCA) → perbaiki permanen. 5. Postmortem (blameless) → action items + retensi sesuai regulasi.

6.3 Playbook insiden umum

7. Kapasitas & Skala

• HPA (Kubernetes) pada service stateless: scale berdasarkan CPU/memori; baseline sesuai docs/04 (1 juta transaksi ≈ 12 TPS rata-rata, puncak 35–58 TPS).
• Kafka: partisi per topik ≥ 3 (produksi), keyed by applicationId agar urutan per pengajuan terjaga; consumer group per service.
• PostgreSQL: read replica untuk report/query berat + PgBouncer untuk connection pooling; jangan SELECT * besar di jalur transaksional.
• MinIO: 4 node erasure-coding (dari docs/04).
• Lakukan load test (k6/Gatling) sebelum event puncak; catat baseline & threshold HPA.

8. Keamanan & Operasional Harian

8.1 Secret & akses

8.2 Deploy & rollback

• Deploy blue/green atau canary per service; jangan deploy semua service serentak.
• Migrasi DB backward-compatible (expand → migrate → contract).
• Rollback: versi sebelumnya tetap tersedia (image tag/registry) + versi proses BPMN blue/green (lihat docs/09).

8.3 Patch & maintenance window

• Patch OS/library bulanan; maintenance window diluar jam sibuk (mis. 00:00–04:00 WIB).
• Siapkan prosedur maintenance: pindahkan traffic, drain node, patch, verifikasi, kembalikan.

9. Runbook Per Layanan (Referensi Cepat)

10. Checklist Periodik

Harian

• [ ] Semua health UP; review alert semalam; cek lag Kafka & error rate.
• [ ] Backup harian PostgreSQL/MinIO sukses (verifikasi ukuran & integritas).

Mingguan

• [ ] Review dashboard kapasitas (CPU/memori/disk) & proyeksi tren.
• [ ] Review log keamanan (login gagal, akses anomali, perubahan konfigurasi).

Bulanan

• [ ] Restore drill: restore backup ke lingkungan uji & verifikasi data.
• [ ] Failover drill: uji cut-over ke SITE B (tanpa memutus produksi bila memungkinkan).
• [ ] Rotasi secret & review akses operator.

Kuartalan

• [ ] Chaos test (matikan DB/Kafka/registry) sesuai checklist docs/04.
• [ ] Review & perbarui BCP/DR dengan hasil drill terakhir.
• [ ] Uji kapasitas kuota SLIK OJK / Pefindo ke vendor.

11. Kesimpulan

Runbook ini menjadikan OriginIQ LOS dapat dioperasikan dengan disiplin standar perbankan: urutan start/stop yang benar, backup yang teruji restore, DR dengan RPO < 15 menit & RTO < 1 jam, monitoring dengan ambang jelas, serta respons insiden ber-severity. Operasikan bersama docs/04 (SLA & skalabilitas), docs/05 (kepatuhan & DRC/BCP), docs/07 (menjalankan di development), dan docs/13 (alur kerja & data) agar produksi aman, cepat, dan diaudit.

15 — Checklist Go-Live & Panduan Deploy (Produksi)

Dokumen ini adalah pintu terakhir sebelum produksi: daftar periksa go/no-go, rencana cutover, dan cara deploy statis. Melengkapi docs/04 (SLA & skalabilitas), docs/05 (kepatuhan), docs/07 (menjalankan), docs/11 (audit keamanan), dan docs/14 (runbook operasional). Jangan go-live sebelum semua item wajib (MUST) terpenuhi.

1. Kriteria Go / No-Go

Go/No-Go: keputusan diambil rapat komite (bisnis, TI, kepatuhan, risiko) — bukan oleh tim teknis saja.

2. Kesiapan Regulasi & Hukum (MUST)

3. Kesiapan Keamanan (MUST)

4. Kesiapan Performa & Kapasitas (MUST)

5. Kesiapan Data & Integrasi (MUST)

6. Kesiapan Operasional (MUST)

7. Rencana Cutover & Rollback

1. Pra-cutover: freeze perubahan fitur; snapshot baseline DB + konfigurasi + versi aplikasi.
2. Cutover: alihkan traffic bertahap (DNS/ingress), mulai dari pilot (1 cabang/segmen).
3. Verifikasi pasca-cutover: health UP, login OK, inquiry SLIK/Pefindo OK, disbursement end-to-end OK, laporan regulator terkirim.
4. Rollback: titik kembali = versi sebelumnya (image tag) + restore DB PITR + rollback konfigurasi; prosedur harus diuji sebelum go-live (bukan saat insiden).

Idempotency pencairan (disbursement.request_id + unique constraint) tetap dijaga selama cutover agar tidak ada pencairan ganda (lihat docs/04 §6).

8. Rencana Peluncuran (Soft → Full)

9. Post-Launch (Hypercare)

• Hypercare 2–4 minggu: tim inti siaga, review harian metrik & insiden.
• Pelaporan regulator: pastikan SLIK bulanan & laporan SPOJK terkirim tepat waktu sejak bulan pertama.
• Review pasca 30 hari: evaluasi kapasitas, keamanan, dan checklist ulang go-live.

10. Deploy Statis (Situs Marketing + SPA)

Situs marketing & SPA bersifat statis — dikemas sebagai image nginx:

# Build & jalankan (menyajikan situs marketing di /, SPA di /app/, proxy /api/ ke gateway)
docker build -f deploy/Dockerfile -t originiq-frontend .
docker run -p 80:80 originiq-frontend

Konfigurasi: frontend/nginx/nginx.conf (header keamanan, gzip, cache aset, proxy API). CI otomatis: .github/workflows/ci.yml (syntax check JS + validasi struktur HTML).

10.1 Deploy Backend (Microservices Spring Boot)

Satu Dockerfile multi-stage melayani semua modul backend (build arg SERVICE):

# Build image per service (contoh auth-service)
docker build -f deploy/Dockerfile.backend \
  --build-arg SERVICE=auth-service -t originiq-auth-service .

Stack penuh (infra + 9 service + frontend) lewat Compose:

cp deploy/.env.example .env        # isi semua secret ("change-me")
docker compose -f deploy/docker-compose.prod.yml build
docker compose -f deploy/docker-compose.prod.yml up -d
docker compose -f deploy/docker-compose.prod.yml ps

• Health probe: Actuator /actuator/health (service) & /eureka/apps (registry); depends_on: condition: service_healthy menjaga urutan startup.
• Backend images: eclipse-temurin:21-jre-alpine (non-root, MaxRAMPercentage).
• Panduan lengkap: deploy/README.md; TLS/keamanan diakhiri di load balancer/ingress.

10.2 Deploy ke Kubernetes (target 1 jt transaksi/hari & SLA 99,95%)

Manifest produksi lengkap di folder k8s/: namespace, ConfigMap + Secret, infra (PostgreSQL/Redis/Kafka/MinIO), 9 service Spring Boot dengan liveness/readiness probe, frontend + Ingress TLS, dan HPA untuk autoscaling (gateway, loan, credit, customer).

kubectl apply -f k8s/                # lihat k8s/README.md untuk build image & secret
kubectl -n originiq-prod get pods,svc,hpa

• Layanan kritis di-replicas: 2 minimal + HPA (target puncak 35–58 TPS — docs/04).
• Database/queue/storage produksi pakai layanan terkelola (RDS, MSK, ElastiCache, S3); manifest k8s/02-infra.yaml adalah referensi single-node.
• Verifikasi pasca-deploy: scripts/smoke-test-prod.sh.

11. Matriks Ringkas Go / No-Go

Keputusan go-live hanya setelah seluruh baris di atas tercentang dan disetujui komite. Lihat docs/14 untuk detail operasional dan docs/04/docs/05 untuk SLA & kepatuhan.