Institutional Settlement Specification

Executive Summary

JIL Sovereign operates a neutral institutional settlement and trust layer. It does not execute trades, custody assets, perform novation, or assume counterparty exposure. Execution, custody, compliance policy, and governance remain with the originating ecosystem - including custodians, venues, issuers, and counterparties.

JIL enforces a standardized settlement process and records finality as the authoritative settlement record. The protocol provides clearing-grade settlement process enforcement: deterministic DvP/PvP leg matching, BFT-quorum finality, cryptographic settlement receipts, and structured reconciliation exports - all without inserting itself into the custody chain or the compliance decision.

Settlement Workflow Overview

The institutional settlement lifecycle consists of five discrete workflow steps. Internally, settlements traverse a 9-state machine (received, validated, compliance_check, accepted, ready, submitted, confirmed, final - plus terminal states rejected, failed, cancelled, expired). Trade execution occurs externally. JIL's scope begins at instruction submission and ends at receipt generation. Each step is deterministic, auditable, and produces cryptographic artifacts.

Trade Execution (External)

A transaction is executed outside of JIL. The execution venue determines the terms - price, quantity, counterparties, and timing. JIL has no visibility into, and no influence over, the trade execution process.

Supported Execution Sources

• Regulated Exchanges - Orders matched on licensed venues (equities, derivatives, digital assets). Exchange provides trade confirmation with standardized reference IDs.
• OTC Desks - Bilateral negotiation between institutional counterparties. Desk provides trade ticket with agreed terms for settlement instruction.
• Custodian Internal Workflows - Book transfers, rebalancing, or internal movements within a custodian's operational scope. Custodian generates settlement instruction from internal records.
• Tokenized Asset Platforms - Primary issuance, secondary transfers, or redemptions on tokenized securities platforms. Platform provides structured settlement data.

Settlement Instruction Submission

An authorized participant submits a structured settlement instruction to JIL. The instruction contains all information required to identify, match, and settle the transaction. JIL validates structural completeness and workflow eligibility. Policy validation - whether the counterparties are permitted, whether the asset is eligible, whether limits are breached - remains with the originating institution.

Required Fields

Validation Rules

JIL performs structural validation only. It does not make policy decisions.

• All required fields must be present and well-formed
• settlementType must be DvP or PvP
• assetQuantity and paymentAmount must be positive non-zero values
• partyA and partyB must be distinct registered participants
• settlementDate must not be in the past
• Duplicate instructionId values are rejected (idempotency guard)

Instruction Schema

{
  "instructionId": "si_8f3a2b91-c4e7-4d8a-b1f3-9e2a7c5d0816",
  "settlementType": "DvP",
  "assetId": "US0378331005",
  "assetQuantity": "1000.00",
  "paymentCurrency": "USD",
  "paymentAmount": "150000.00",
  "partyA": "LEI:5493001KJTIIGC8Y1R12",
  "partyB": "LEI:213800WSGIIZCXF1P572",
  "tradeRef": "TR-2026-0215-001",
  "settlementDate": "2026-02-15T00:00:00Z",
  "metadata": {
    "venue": "NYSE",
    "assetClass": "equity",
    "settlementCycle": "T+1"
  }
}

DvP / PvP Process Enforcement

JIL enforces deterministic settlement logic. Both legs of a settlement must be present, matched, and confirmed before final commitment. No unilateral release is permitted under any circumstances. This is the core process guarantee that JIL provides.

Delivery versus Payment (DvP)

Asset delivery occurs if and only if payment is confirmed. Both legs must be present and matched before final settlement is committed. If one leg fails, settlement does not occur - neither the asset nor the payment moves. Each leg undergoes independent compliance evaluation - the asset leg and payment leg are checked separately for sanctions, AML, jurisdiction, and travel rule requirements.

Payment versus Payment (PvP)

Payment A is released if and only if Payment B is confirmed. This mode is used for FX settlement, cross-currency swaps, and multi-currency treasury operations. No unilateral release is permitted.

JIL enforces bilateral leg integrity before final commitment. The PvP engine treats both payment legs symmetrically - neither has priority, and both must satisfy readiness checks simultaneously. Per-leg compliance is applied - each payment leg is independently evaluated for sanctions, AML, and jurisdiction requirements before the settlement can progress to READY state.

Travel Rule Evaluation

For FI-to-FI and FI-to-Crypto settlement lanes, JIL evaluates travel rule requirements during the COMPLIANCE_CHECK state. If the settlement exceeds the applicable threshold (typically $3,000 USD equivalent under FATF guidance), originator and beneficiary information must be included in the instruction metadata. Travel rule evaluation is performed per-leg for DVP/PVP settlements. Crypto-to-Crypto settlements below threshold are exempt from travel rule requirements but still undergo sanctions screening.

Matching Rules

Failure Modes

• Partial Leg Failure - If one leg is submitted but the counterparty leg never arrives within the timeout window, the instruction transitions to CANCELLED. No settlement occurs. The submitting party is notified.
• Readiness Timeout - If both legs are matched but one party never confirms readiness, the instruction transitions to FAILED after the readiness timeout. Both parties are notified with the failure reason.
• Validation Rejection - If an instruction fails structural validation (malformed fields, duplicate ID, past settlement date), it is immediately rejected with a structured error response. No state is created.
• Quorum Failure - If BFT quorum cannot be achieved during the finality step (fewer than 14-of-20 validators available), the instruction remains in READY state and retries until quorum is restored or timeout expires.

Beneficiary Verification & BEC Prevention

JIL enforces cryptographic beneficiary identity binding on every settlement instruction. This prevents Business Email Compromise (BEC) attacks - where an attacker redirects funds by modifying beneficiary details in intercepted payment instructions - by requiring a signed commitment to the beneficiary's identity before settlement begins.

API Integration Requirements

The POST /v1/settlements request body must include a beneficiary_binding object for all institutional (FI-to-FI) settlement lanes. The binding is optional for Crypto-to-Crypto settlements but recommended.

Binding Hash Computation

The binding hash is computed by the originating institution before submission:

canonical_payload = JSON.stringify({
  beneficiary_account: "GB29NWBK60161331926819",
  beneficiary_lei: "529900T8BM49AURSDO55",
  instruction_id: "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
})
binding_hash = SHA-256(canonical_payload)   // 64-char hex
binding_signature = Ed25519.sign(binding_hash, originator_private_key)

State Machine Impact

Beneficiary verification is enforced at two points in the settlement state machine:

Pre-Registration (Optional)

Institutions can pre-register known beneficiary relationships via POST /v1/beneficiary-bindings. Pre-registered bindings are cached and verification is instant. Ad-hoc bindings (first-time beneficiary) undergo full verification including sanctions screening of the beneficiary account and country.

Evidence Bundle Addition

When a settlement reaches FINAL state, the settlement_receipt JSONB includes three additional fields for BEC audit trail:

Deterministic Finality

Once all conditions are satisfied - both legs matched, both parties confirmed readiness, and no validation exceptions - the settlement event is committed under BFT quorum consensus. The finality state is achieved, a timestamped and hashed settlement record is written, and the settlement status transitions to Final.

This record becomes the authoritative settlement artifact. It is immutable, cryptographically verifiable, and referenceable by all parties and auditors.

BFT Quorum Requirements

Settlement State Machine (9 States)

Every settlement instruction transitions through a deterministic 9-state machine. No state can be skipped, and transitions are irreversible (except for terminal states, which may be retried with a new instruction). Fees are calculated at the FINAL state, not at submission.

RECEIVED → VALIDATED → COMPLIANCE_CHECK → ACCEPTED → READY → SUBMITTED → CONFIRMED → FINAL

Terminal states: REJECTED, FAILED, CANCELLED, EXPIRED

Settlement Lanes

Every settlement is classified into one of three lanes based on the nature of the counterparties. Lane classification determines compliance depth, fee schedule, and reconciliation export format.

Settlement Receipts & Reconciliation

Upon finality, JIL issues a comprehensive set of cryptographic settlement artifacts. These artifacts are designed for institutional straight-through processing (STP), audit workflows, and regulatory reporting. Every artifact is independently verifiable without contacting JIL.

Settlement Artifacts

Receipt Structure

{
  "receiptId": "sr_4c7e1a93-b8d2-4f6e-a3c9-1d5f8e2b7a04",
  "instructionId": "si_8f3a2b91-c4e7-4d8a-b1f3-9e2a7c5d0816",
  "status": "FINAL",
  "settlementHash": "0x7a3b9c1d4e5f6a2b8c0d1e3f5a7b9c2d4e6f8a0b",
  "finalityTimestamp": "2026-02-15T14:32:07.891Z",
  "blockHeight": 1847293,
  "quorum": {
    "threshold": "14-of-20",
    "signers": 17,
    "attestation": "0x1a2b3c4d5e6f..."
  },
  "parties": {
    "partyA": "LEI:5493001KJTIIGC8Y1R12",
    "partyB": "LEI:213800WSGIIZCXF1P572"
  },
  "tradeRef": "TR-2026-0215-001"
}

Reconciliation & STP

Settlement receipts and reconciliation exports are available via API immediately upon finality. Institutions can subscribe to webhook notifications for real-time settlement updates, or poll the API for batch reconciliation. Export formats include JSON (native), CSV (tabular), and ISO 20022 pacs.002 (SWIFT-compatible).

Settlement Premium

The institutional settlement premium of 3-5 basis points applies only to final settlement events recorded on JIL as the authoritative settlement record. Fees are calculated at the FINAL state - not at submission or any intermediate state. If a settlement never reaches finality, no fee is incurred. The premium compensates for validator infrastructure, BFT consensus, cryptographic receipt generation, and reconciliation services.

Fee Structure

Exclusions

Gas Burn

Base gas is burned 100 percent. The settlement premium is the only revenue mechanism. There are no hidden fees, platform taxes, or extraction mechanisms. Gas burn ensures that the native token has a deflationary pressure proportional to network utilization.

Policy vs Process Boundary

JIL draws a clear and deliberate line between policy (what participants decide) and process (what JIL enforces). This separation is the foundation of JIL's neutrality and the reason institutions can adopt JIL without surrendering governance authority.

Institutional Boundary Statement

JIL Sovereign is infrastructure. The following capabilities are explicitly outside JIL's scope:

• Does Not Custody Assets - JIL never takes possession of, or control over, participant assets. All assets remain in participant-controlled custody throughout the settlement lifecycle.
• Does Not Execute Trades - JIL does not operate an exchange, matching engine, or execution venue. Trade execution is entirely external to JIL.
• Does Not Perform Novation - JIL does not interpose itself as a counterparty. The original trade relationship between parties is preserved through settlement.
• Does Not Assume Counterparty Exposure - JIL bears no credit risk, market risk, or settlement guarantee. The DvP/PvP process eliminates principal risk through atomic execution.
• Does Not Guarantee Settlement Financially - JIL provides process enforcement, not financial guarantee. If both legs are not present, settlement does not occur - that is the guarantee.
• Does Not Make Compliance Decisions - JIL does not evaluate KYC status, sanctions lists, or regulatory eligibility. These decisions remain entirely with participants.

Technical Integration Guide

API Endpoints

Submit Instruction Example

POST /v1/settlements
Authorization: Bearer <jwt>
Content-Type: application/json

{
  "settlement_type": "DVP",
  "lane": "FI_TO_FI",
  "assetId": "US0378331005",
  "assetQuantity": "1000.00",
  "paymentCurrency": "USD",
  "paymentAmount": "150000.00",
  "partyA": "LEI:5493001KJTIIGC8Y1R12",
  "partyB": "LEI:213800WSGIIZCXF1P572",
  "tradeRef": "TR-2026-0215-001",
  "settlementDate": "2026-02-15T00:00:00Z"
}

Response Example

HTTP/1.1 201 Created

{
  "id": "stl_8f3a2b91-c4e7-4d8a-b1f3-9e2a7c5d0816",
  "status": "RECEIVED",
  "settlement_type": "DVP",
  "lane": "FI_TO_FI",
  "createdAt": "2026-02-15T14:30:12.456Z",
  "settlementDate": "2026-02-15T00:00:00Z",
  "timeout": "2026-02-16T14:30:12.456Z",
  "links": {
    "self": "/v1/settlements/stl_8f3a2b91...",
    "attest_ready": "/v1/settlements/stl_8f3a2b91.../attest-ready",
    "cancel": "/v1/settlements/stl_8f3a2b91.../cancel"
  }
}

Webhook Payload

{
  "event": "SETTLEMENT_FINAL",
  "id": "stl_8f3a2b91-c4e7-4d8a-b1f3-9e2a7c5d0816",
  "status": "FINAL",
  "settlement_type": "DVP",
  "lane": "FI_TO_FI",
  "settlementHash": "0x7a3b9c1d4e5f6a2b8c0d1e3f5a7b9c2d4e6f8a0b",
  "finalityTimestamp": "2026-02-15T14:32:07.891Z",
  "fee": {
    "amount": "52.50",
    "bps": 3.5,
    "calculated_at": "2026-02-15T14:32:07.891Z"
  },
  "receiptUrl": "/v1/settlements/stl_8f3a2b91.../receipt"
}

Implementation Notes

The following guidance is provided for developers integrating with the JIL settlement layer or building settlement-related services.

• DvP and PvP logic must require dual-leg confirmation with per-leg compliance before final commit. No single-leg settlement is permitted under any condition.
• Settlement status states must include all 9 states: RECEIVED, VALIDATED, COMPLIANCE_CHECK, ACCEPTED, READY, SUBMITTED, CONFIRMED, FINAL, plus terminal states REJECTED, FAILED, CANCELLED, EXPIRED. State transitions must be logged and auditable.
• Fees must be calculated at the FINAL state, not at submission or any intermediate state. Settlements that do not reach finality must incur no fee.
• Travel rule evaluation must be performed during the COMPLIANCE_CHECK state for FI-to-FI and FI-to-Crypto lanes when the settlement exceeds the applicable threshold.
• Finality commit must require 14-of-20 quorum consensus. Do not implement finality without quorum verification.
• Settlement receipts must be hash-based, timestamped, validator-signed, and referenceable via API.
• Reconciliation exports must be structured for institutional STP compatibility (JSON, CSV, ISO 20022 pacs.002).
• All API requests must be authenticated via JWT with institutional-grade key management.
• Implement idempotency guards on instruction submission - duplicate instructionId values must be rejected, not re-processed.
• Timeout handling must be deterministic: configurable per instruction, with clear transition to terminal state on expiry.