Settlement Process Flow
End-to-end view of how a settlement instruction moves through identity binding, policy evaluation, escrow, BFT consensus, and evidence bundle generation. Four phases, ten steps, deterministic finality.
Eight states from instruction to finality
Intake and Identity Binding
An authorized participant submits a structured settlement instruction. Beneficiary identity is verified and the instruction is structurally validated before any further processing.
Instruction Submission
An authorized participant submits a structured settlement instruction via the Settlement Integrity API.
- Instruction includes settlement type (SIMPLE, DVP, or PVP), asset, amount, and party identifiers
- Beneficiary Identity (BID) reference attached - binds payment to verified recipient
- Lane auto-classified based on party types: FI-to-FI, FI-to-Crypto, or Crypto-to-Crypto
- State transitions to
RECEIVED
Beneficiary Identity Verification
Settlement engine resolves the BID references and verifies endpoint integrity before proceeding.
- BID directory lookup confirms both parties are active and verified
- Endpoint version checked - detects if payout details were recently changed
- If endpoint was modified within the hold window, settlement is held for manual review
- Prevents beneficiary spoofing and invoice redirection attacks
Structural Validation
Engine validates the instruction structure and transitions to VALIDATED.
- All required fields present and well-formed
- Settlement type valid (SIMPLE / DVP / PVP)
- Amounts positive, parties distinct, settlement date not in past
- No duplicate instruction IDs
- For DVP/PVP - both legs present and structurally matched
Policy and Compliance Control
The instruction passes through policy evaluation, compliance screening, and readiness attestation. Institutions configure their own rules - JIL enforces them deterministically.
Policy Engine Evaluation
The policy engine evaluates the instruction against configured approval rules before compliance screening.
- Maker-checker approval requirements evaluated
- Threshold rules applied - large settlements may require additional signers
- Escrow window rules applied if configured (hold period before release)
- Circuit breaker checks - velocity limits, daily caps, unusual pattern detection
- Policy is enforced, not decided - institutions configure their own rules
Compliance Screening (Fail-Closed)
Multi-layer compliance evaluation runs. State transitions to COMPLIANCE_CHECK. If compliance-api is unreachable, settlement is blocked - never bypassed.
- Sanctions screening against OFAC, EU, and UN consolidated lists
- AML evaluation and jurisdiction containment checks
- Travel rule evaluation (required for settlements > $3,000 USD equivalent)
- For DVP/PVP - per-leg compliance applied independently
- If all checks pass, state transitions to
ACCEPTED
Readiness Attestation
Behavior branches based on settlement type. Settlement transitions to READY once both parties confirm (DVP/PVP) or automatically (SIMPLE).
- DVP/PVP readiness timeout: 24 hours (configurable)
- If one party never confirms, settlement transitions to
FAILED - Escrow may hold funds during the attestation window if policy requires it
SIMPLE
Auto-promoted from ACCEPTED to READY. No manual attestation required. Single-leg transfer proceeds immediately.
DVP (Delivery vs Payment)
Both parties must attest readiness. Asset leg and payment leg matched. Atomic guarantee - both commit or neither commits.
PVP (Payment vs Payment)
Both payment legs treated symmetrically. Neither has priority. Used for FX settlement and cross-currency operations.
Ledger Commit and BFT Finality
The settlement instruction is submitted to the JIL L1 ledger and committed under 14-of-20 BFT quorum consensus. Deterministic finality - not probabilistic.
Ledger Submission
Settlement instruction submitted to the JIL L1 settlement ledger. State transitions to SUBMITTED.
- Instruction queued for inclusion in next available block
- Zone-based compliance enforced at consensus layer - validators reject non-compliant transactions at mempool
- Block time: 1.5 seconds
- Once included in a block, state transitions to
CONFIRMED
BFT Consensus Finality
Settlement committed under 14-of-20 BFT quorum consensus. State transitions to FINAL - irreversible and authoritative.
- 20 active validators across 13 jurisdictions independently verify the settlement
- 6 block confirmations required (~9 seconds at 1.5s block time)
- Deterministic finality - not probabilistic. Required for institutional settlement.
- Settlement fees calculated at this point - no fee if settlement never reaches finality
- Timestamped and hashed settlement record created
Evidence and Reconciliation
Upon finality, JIL generates a comprehensive cryptographic evidence bundle and delivers settlement confirmation for straight-through processing.
Evidence Bundle Generation
Upon finality, JIL generates a comprehensive cryptographic evidence bundle - the audit-ready proof of settlement.
- Settlement Receipt - JSON payload with Ed25519 digital signature
- Settlement Hash - SHA-256 content hash for non-repudiation
- ISO 8601 UTC Timestamp - precise time of finality commitment
- Quorum Attestation - 14-of-20 multi-signature validator proof
- BID Binding Record - proof that payment reached the verified beneficiary
Reconciliation Export
Institutions receive settlement confirmation and can export reconciliation data in multiple formats.
- Webhook notification delivered to subscribed endpoints
- Export formats: JSON, CSV, or ISO 20022
pacs.002 - STP-compatible - designed for direct ingestion by back-office systems, OMS platforms, and fund administrators
- Batch reconciliation available via polling API
- Evidence bundle permanently stored and cryptographically verifiable
Four integrity mechanisms that make settlement fraud structurally impossible
Beneficiary Identity Binding (BID)
Core integrity mechanism. BID ensures every payment reaches the verified beneficiary - not just the account number. Each beneficiary has a versioned identity record with approved payout endpoints. Endpoint changes require approval workflow with configurable hold windows. First-payment risk detection for new beneficiaries. BID verification is mandatory - settlements cannot proceed without verified identity binding.
Policy Engine - Approve, Escrow, Release
Institutions configure their own rules. JIL enforces workflow integrity. Maker-checker approval chains with configurable signer requirements. Threshold-based escalation for large settlements. Escrow windows with cancel/freeze capability before release. Circuit breakers for velocity limits, daily caps, and unusual pattern alerts. Policy is enforced deterministically and logged for audit trails.
Deterministic Finality (Not Probabilistic)
Required for institutional settlement. CometBFT consensus provides deterministic finality - once FINAL, the settlement cannot be reversed. 20 validators across 13 compliance jurisdictions. 14-of-20 BFT quorum required for finality commitment (70% fault tolerance). Tolerates up to 6 simultaneous validator failures. No reorganizations, no probabilistic confirmation waiting, no settlement reversals. Total time from READY to FINAL: under 5 seconds.
Evidence Bundles - Accelerate Investigations
Audit-ready proof artifacts. Every settlement produces a cryptographic evidence bundle for disputes, investigations, and regulatory reporting. Settlement receipt with Ed25519 digital signature - tamper-proof. SHA-256 content hash for non-repudiation. Quorum attestation proving 14+ validators independently confirmed the settlement. ISO 20022 compatible exports for straight-through processing.
Terminal States
| State | Trigger | Description |
|---|---|---|
REJECTED |
Validation failure | Malformed fields, duplicate instruction ID, settlement date in past, or invalid party identifiers |
FAILED |
Readiness timeout | Both legs matched but one party never confirmed readiness within the timeout window (default 24h) |
CANCELLED |
Partial leg failure | Counterparty leg never arrives, or an authorized party explicitly cancels the instruction |
EXPIRED |
TTL exceeded | Instruction timeout exceeded (24h) without reaching a terminal state |
Key API Endpoints
| Service | Endpoint | Method | Purpose |
|---|---|---|---|
| settlement | /v1/settlement/instructions | POST | Submit new settlement instruction |
| settlement | /v1/settlement/instructions/:id | GET | Query settlement state and details |
| settlement | /v1/settlement/instructions/:id/confirm | POST | Confirm readiness (DVP/PVP attestation) |
| compliance | /check/tx | POST | Sanctions and AML screening |
| proof | /v1/settlement/instructions/:id/receipt | GET | Download settlement receipt and evidence bundle |
| proof | /v1/settlement/instructions/:id/export | GET | Export reconciliation (JSON / CSV / pacs.002) |
| BID | /v1/bid/verify | POST | Verify beneficiary identity and endpoint status |
Related Documentation
Neutral Settlement Protocol
Three-lane architecture overview, settlement types, and fee structure comparison.
View Document →Settlement Lifecycle
Detailed 9-state machine, database schema, and terminal state handling.
View Document →Settlement API Specification
Complete API reference for settlement endpoints, request/response schemas.
View Document →Institutional Settlement Spec
Technical specification for institutional integration and compliance requirements.
View Document →Institutional Brief
Executive summary of JIL settlement capabilities for decision-makers.
View Document →From instruction to deterministic finality in under 5 seconds
Ten steps, four phases, 14-of-20 BFT consensus, and a cryptographic evidence bundle on every settlement. No probabilistic waiting. No settlement reversals.