Market openUSD/KRW 1,507.90JPY/KRW 9.730
demo@netfx.dev

Roadmap — to confirm later

Operational readiness review — counterparty / legal / operational limits
Beyond the compression algorithm — items to clean up before connecting to live trading systems. In the current prototype these are handled with *implicit assumptions* or simplifications.
Section 1 — counterparty / legal / operational limits
KYC / LEI verification
Not implemented
Once at compression onboarding
Meaning
Whether this legal entity is eligible to join the compression service — LEI validity, AML screening, sanctions-list matching.
Current state
The LEI field exists in the mock but there is no verification logic. In practice every mock entity passes automatically.
Future work
  • ·GLEIF / LEI search API integration to confirm LEI active status
  • ·AML screening (sanctions lists, PEP) — third-party service or manual entry
  • ·Participant onboarding page: enter LEI → auto-verify → status display (Pending/Active/Suspended)
Effort: Medium (external API integration + UI)
ISDA Master + CSA
Implicit assumption
Once at bilateral agreement
Meaning
Legal netting framework between two dealers. On default, bilateral close-out netting is possible. Ensures residual trades created by compression are automatically included in bilateral netting.
Current state
The cp_nets monotonicity constraint *implicitly* assumes an ISDA exists. It does not explicitly prevent new exposure from being created on a pair with no ISDA.
Future work
  • ·(dealer A, dealer B) → ISDA-existence matrix data model
  • ·LP scope constraint: pairs with no ISDA are excluded as edges or set x_e = 0
  • ·CSA terms (collateral threshold, MTA, collateral currency) — v2
  • ·Dealer × dealer ISDA matrix toggle UI in Settings
Effort: Medium (LP + UI, 2-3h)Task #1
Trading / credit line
Not implemented
Day-to-day operations (real-time)
Meaning
The exposure limit dealer A allows to dealer B. If the ISDA is *legal eligibility*, the trading line is the operational limit of *how much is actually possible today*. The matrix the daily desk watches every day.
Current state
The cp_nets ε relaxation *indirectly* limits bilateral net movement — there is no standalone limit. Compression can produce a result that exceeds the line cap in absolute terms.
Future work
  • ·(A, B) pair → max |net exposure| matrix
  • ·LP constraint: |post_net| ≤ line(A, B)
  • ·Combined with the ISDA matrix: line = 0 automatically when no ISDA
  • ·Line matrix editing UI in Settings (per-tier defaults + inline editing)
Effort: Medium (1-2h, combined with the ISDA matrix work)
NDD novation package
Not implemented
On demand — when a local wants to receive NDD
Meaning
Let a local counterparty (local securities firm or bank) receive the deliverable (NDD) side: package the position via novation and hand it to a specific named counterparty, subject to all counterparties' approval. The receiver earns a spread of 30 jeon (1Y) / 15 jeon (6M). Structure: ND buy/sell + D sell/buy, with the offsetting position held by a foreign counterparty.
Current state
Not implemented. Compression currently only terminates or rate-resets within existing counterparties — there is no novation or package transfer to a new named entity.
Future work
  • ·Novation flow: package a position as an 'NDD package' and transfer to a specific receiving name (local securities firm / bank)
  • ·Pre-novation gate: check the receiver's credit limit AND IM (initial margin) limit — novate only if within both
  • ·Receiver pricing: spread to the receiver — 30 jeon (1Y) / 15 jeon (6M)
  • ·Position structure: ND buy/sell + D sell/buy; offsetting position with a foreign counterparty
  • ·Counterparty consent: all involved counterparties must approve the novation
  • ·Transferor-set cost: the existing ND-position holder can set a transfer cost (~5-10 jeon); the receiver takes the package inclusive of that cost, folded into the 6M / 1Y pricing
Effort: Large (novation engine + credit / IM limit checks + consent)
Section 2 — infrastructure / regulatory / data retention
DTCC / CLS / SWIFT connectivity
Not implemented
Every time after a cycle completes
Meaning
Transmit compression LP results to the actual trade booking system. In the simulator this is only an in-memory mutation; in live trading it must propagate to external settlement infrastructure to be meaningful.
Current state
Cycle results are applied to in-memory state.trades and shown in the UI. No external transmission.
Future work
  • ·DTCC TIW/TR — terminated trade list + replacement trade booking + compression event
  • ·CLS Bank — update net obligation for CLS-eligible settle.method trades
  • ·SWIFT — MT 300 / MT 304 (bilateral confirmation / compression notice)
  • ·Domestic settlement networks (KFTC, BOK-Wire+) — DOMESTIC settle trades
  • ·Idempotency / retry / audit log
Effort: 1-2 weeks (external API authentication + message mapping)Task #2
Audit trail / regulatory reporting (Basel SA-CCR)
Not implemented
On cycle completion + periodic reporting
Meaning
Persist every cycle decision / mutation. Output the before-and-after change in SA-CCR EAD / RC / PFE add-on in BIS / FSS formats.
Current state
Cycle results are stored in an in-memory Map. Lost on server restart. No SA-CCR format output.
Future work
  • ·DB persistence: cycle, trade-mutation, audit event (5-10 year retention)
  • ·Tamper-evident — hash chain or write-once storage
  • ·SA-CCR report generator — EAD per cp, PFE add-on, Replacement Cost change
  • ·EMIR Article 39 / Dodd-Frank Title VII formats (where applicable)
  • ·'Download SA-CCR report' button on the Cycle detail page
Effort: 1-2 weeks (DB schema + templates + UI)Task #3
Multi-tenant DB / SOC 2 / data retention
Not implemented
Service operating infrastructure
Meaning
Data separation per dealer / fund, RLS, encryption. SOC 2 Type II certification for financial-institution trust. PIPA / GDPR compliance.
Current state
In-memory store (globalThis singleton). No multi-user separation. No authentication / access control / persistence.
Future work
  • ·Postgres + Supabase Auth (lib/supabase partially in place) — Phase 1
  • ·Row-level security — dealer A sees only their own trades (cross-tenant aggregates only within a compression cycle)
  • ·SOC 2 Type II — controls: SSO/MFA, separation of duties, change management, incident response, DR plan
  • ·5-10 year data retention + encryption (KMS, key rotation) + GDPR/PIPA right to erasure
  • ·Disaster recovery: multi-region replication, periodic failover drills
Effort: 3-6 months (through full SOC 2) / DB infrastructure alone 1-2 weeksTask #4
The algorithm is near-parity; the operational infrastructure differs
The compression math itself reaches production-grade level. The three items above + external system connectivity (DTCC/CLS/SWIFT) + audit trail + multi-asset expansion are the remaining distance to live operation.
Completed (algorithm / simulator)
  • ✓ Multi-criteria LP / QP / Sequential LP
  • ✓ 7 constraints (cash / timing / DV01 / concentration / cp_net / reset / liquidity floor)
  • ✓ Trade-level mid (Phase 3B — accurate cap satisfaction)
  • ✓ Phase 1 netting + Phase 2 rate reset (6M/1Y only)
  • ✓ PFE / SA-CCR EAD KPI
  • ✓ Dealer × currency net exposure matrix
  • ✓ 6-category trade outcome classification
  • ✓ Sub-portfolio exclusion (BtoB / unwind request)
  • ✓ Mock calibration (Pareto cp, bimodal tenor, log-normal size)
Pending (operations / infrastructure)
  • ○ KYC / LEI verification (Section 1)
  • ○ ISDA / CSA matrix (Section 1 · Task #1)
  • ○ Bilateral trading line cap (Section 1)
  • ○ DTCC / CLS / SWIFT transmission (Section 2 · Task #2)
  • ○ Audit trail / SA-CCR reporting (Section 2 · Task #3)
  • ○ Multi-tenant DB / SOC 2 (Section 2 · Task #4)
  • ○ Dealer-side dashboard (participant's own view)
  • ○ Pending CP approval workflow (notify both sides)
  • ○ Multi-asset expansion (IRS / CDS / Inflation)
  • ○ Real-time mid feed (broker / vendor)
  • ○ NDD novation package (credit / IM-gated transfer + consent)