Duit

CREATE CONSTRAINT TRIGGER ledger_entries_balanced
    AFTER INSERT ON core.ledger_entries
    DEFERRABLE INITIALLY DEFERRED
    FOR EACH ROW EXECUTE FUNCTION core.check_transaction_balanced();

• Debit = credit per transaction with at least two entries, checked once at commit by a deferred trigger
• Transactions and entries are append-only: corrections are always new entries
• Customer balances can't go negative, closed accounts must be at zero, and money is stored as BIGINT rupiah, never float
• Posting locks every touched account with SELECT … FOR UPDATE ordered by ID to avoid deadlocks
• The cached balance column is reconciled against entry totals, and even seed balances come from a genesis transaction

• Unique ledger idempotency keys namespaced per action, e.g. dret-transfer:<id>, payroll-item:<id>, dpay-payment:<id>
• API-level table storing request hash + response; same key with a different body is rejected with 409
• Every cash-deposit form carries its own key, and DPAY requires Idempotency-Key on invoice creation
• Self-found bug: Poch keys weren't namespaced per customer and action, so closing a Poch with an old key could strand funds. Reproduced with an integration test first, then fixed without a new table

BEGIN
  SELECT … FROM core.kyc_submissions WHERE id = $1 FOR UPDATE   -- lock the row
  check status is still pending_approval
  check checker ≠ last reviewer
  write review (append-only), update status, open savings account
COMMIT

• The same pattern covers deposit approvals, current-account opening, corporate activation, config changes, and MDR/limit changes
• Critical separations are DB constraints too: teller and supervisor can't be the same account
• Teller daily limits use a per-teller advisory lock so two simultaneous deposits can't both slip under the cap

Maker     upload CSV, name mismatches decided per row (recorded)
Approver → Releaser (same group, three different people)
Release   batch total: Current account → Payroll Clearing (2100)
Worker    each row: Clearing → employee account (re-check active + KYC)
          failed rows: Clearing → Current account
Done      clearing balance for this batch returns to zero

• One DB transaction per row with key payroll-item:<id>
• Held funds show up on the balance sheet as a liability, not a hidden flag
• Name mismatches go to the maker, because HR data often spells names differently from bank records

• The app gets "being verified" immediately; a worker calls the registry in the background
• Retry with backoff from 5 seconds up to 5 minutes; workers claim jobs with FOR UPDATE SKIP LOCKED
• Each decision is stored as a snapshot (request, per-field result, score, threshold, attempt), so today's decision stays explainable if the rules change tomorrow
• Name matching normalizes titles and name variants, then scores with Jaro-Winkler (≥ 0.95 match, ≥ 0.80 partial)

• AES-256-GCM encryption with an HMAC-SHA256 blind index for duplicate checks (one ID = one customer)
• Lists and snapshots only show masked IDs; full IDs from the registry are masked before storing
• Opening full KYC details writes a kyc.viewed audit event
• ID photos live in object storage behind 10-minute presigned URLs; the app key can't delete

New phone   correct phone + PIN → "new device, enter DMT code"
Old phone   warned about a login attempt from a new device
DMT         unlocked by PIN/biometrics → 6-digit TOTP code
New phone   code accepted → becomes the bound device, old sessions revoked
Old phone   401 device_replaced

• Each install creates an Ed25519 key pair in Keychain/Keystore; the server only stores the public key and verifies signed, timestamped challenges
• TOTP: 6 digits, 30 seconds, ±1 step, no code reuse; secrets encrypted at rest
• Wrong PIN returns 422 instead of 401 so the app doesn't log out; weak PINs are rejected
• Refresh tokens rotate with reuse detection, isolated per channel

BEGIN
  dpay.BeginPaymentTx     lock invoice, check status, expiry, merchant daily limit
  core.DPAYPaymentTx      debit payer, credit merchant (amount − MDR), credit MDR income
  dpay.CompletePaymentTx  mark paid, enqueue payment.paid webhook (outbox)
COMMIT

• An invoice can't be paid without a journal, a journal can't exist without a paid invoice, and webhooks only go out if both commit
• MDR (0–5% per merchant) is set by the bank through maker-checker and booked to its own income account, rounded down
• The back-office balance sheet shows current-period profit so it still balances once the bank earns revenue

signature = hex(HMAC-SHA256(secret,
    METHOD \n PATH?QUERY \n TIMESTAMP \n hex(SHA256(body))))

• ±5 minute timestamp window against replay, 120 req/min per key, 429 after 20 bad signatures per IP
• Production keys need a second sysadmin's approval, and the secret can be retrieved once, only by the requester, within 24 hours
• Key rotation with a 24-hour grace period; webhooks carry two signatures during rotation
• Webhook retries at 1m, 5m, 30m, 2h, 6h, 12h, then manual resend
• SSRF protection when the URL is saved and again when connecting (against DNS rebinding); redirects aren't followed

• Other modules can only go through public functions like core.TransferTx
• Breaking the boundary fails the build instead of just breaking a convention
• The registry is a fully separate Go module and database, reached only over HTTP

• Approached from both an outside attacker's and an insider's point of view
• Fixes prioritized by impact; some critical findings are mitigated, others are explicitly accepted for the simulation and tracked as open
• Key insight: database constraints stop bugs, but not people with database credentials, which leads to separate migration/app users, hash chains, and off-DB log copies