Inputs
The engine receives your price feed, product configuration and order instructions. For each client trade it tracks the relevant state (entry, trigger, termination) without altering your existing order routing or execution venues.
How the CRL engine works
Technically, CRL is a leverage engine that sits between your price feed and your order management. It does not replace your platform and it does not touch execution or custody.
The core design principle is simple: until a specific trigger is hit, the client behaves as if they were essentially linear. When the trigger is confirmed, the whole move from entry is multiplied according to a predefined rule, with a payoff that can be hedged and reported using standard tools.
For your CTO and architects
CRL is designed as a narrow, well-defined engine sitting between your price feed and your order / risk systems. No custody, no execution, no client-facing UI: just deterministic payoff calculations that your own systems can book, hedge and report.
Integration surface
REST API over mTLS with HMAC authentication per institution. You send instrument, direction, size and configuration; the engine returns a full payoff path and risk metrics.
Security and isolation
mTLS, IP allow-listing and HMAC keys segregated per institution. CRL never stores client login credentials or payment details. Logs are append-only and WORM-compatible.
Performance
The engine is deterministic and sized to sit within the latency budgets of professional trading stacks. Standard metrics for latency, error rates and per-tenant throughput.
Tooling
OpenAPI specification, Postman collection and example client code so your team can exercise the API on day one. SDK available if needed.
Monitoring & Audit
CRL runs with continuous operational monitoring and an integrity-grade audit trail designed for professional counterparties.
Observability
Prometheus-based metrics and Grafana dashboards track latency (p50/p95/p99), error rates, upstream health, and capacity signals across the API and core engine.
Security telemetry
Authentication failures are measured by reason (unknown key, bad signature, timestamp out of range) to support operational and security review.
Audit integrity
Each calculation emits a structured audit event with cryptographic linkage (prev-hash chaining) and daily Merkle tree batching. Tamper-evident by design: any modification breaks the hash chain.
Cryptographic signing
Daily Merkle roots signed with AWS KMS Multi-Region Keys (RSA-2048). Keys rotatable via alias without service interruption. Signatures stored in S3 WORM for MiFID II Article 16 compliance.
Snapshot (Dec 2025): monitoring targets 8/8 up • 5,900+ audit events recorded • 0 signature failures in latest integrity checks.
From linear exposure to conditional leverage
CRL does not add hidden exposure to your book. It reshapes when leverage appears and how it is accounted for. Each CRL position lives in a small, finite set of states that your risk team can read in plain language. In risk terms, you move from an always-leveraged profile, where the client is exposed from the first tick, to a structure where leverage only appears once the move you care about has actually happened.
1
Pre-trigger: essentially linear
The client enters a CRL trade. Until the trigger level is reached, the position behaves like a non-leveraged exposure with a clearly defined notional and direction. There is no hidden leverage in the book at this stage.
2
Trigger: activation and retro calculation
When the market reaches the agreed trigger, the engine locks the path from entry and applies the leverage rule to that whole move. At this moment the position becomes a leveraged payoff with an explicit strike, notional and settlement formula.
3
Post-trigger: settlement and closure
Once activated, the position follows a clear, bounded payoff until termination. The engine returns the resulting P&L, and your systems treat it as they would treat any other structured payoff: settlement, booking and reporting follow your normal procedures.
What the engine consumes and what it returns
CRL is built to live on your own market data and infrastructure. It does not generate prices and it does not become a second book of record. Your systems remain the source of truth; CRL is a calculation and payoff engine that reacts to what you feed it.
State & risk view
Each CRL position is stored with explicit states and parameters that your risk and product teams can read: current status, potential activation level, realised trigger, and payoff parameters. This makes it possible to run monitoring, stress and exposure views using the same tools you already use.
Outputs
The engine returns deterministic payoffs and settlements for each position, together with the information required for booking and reporting. You decide how these flows are mapped into your existing systems (accounts, ledgers, reports).
How dealers integrate CRL in 4 steps
CRL is not a trading venue or a book of record. It is a leverage engine that sits inside your existing stack. The path to production is incremental: you start with read-only visibility, then move to a small, hedged pilot, and only scale once risk, P&L and capital impact are fully understood.
1
Inventory visibility
Connect CRL to your existing position and order data. Build a shared view of net exposure by symbol, book and product type, including CRL states. No product changes, no new hedging yet: this is pure transparency.
2
Controlled pilot
Enable CRL on a small universe of underlyings and professional clients. Define explicit hedging rules per state (pre-trigger, near-trigger, post-trigger) and monitor P&L, VaR and hedge costs against your current leverage products.
3
Scale and automate
Extend coverage to more desks and symbols. Use the Hedge Intent and Coverage Plan to net hedges across the portfolio (“hedge once, serve many”) and integrate CRL metrics into your existing risk and treasury views.
4
Capital & revenue integration
Calibrate CRL premiums and spreads on your own data so that, at portfolio level, premiums and spreads exceed disciplined hedging and tail-risk costs under explicit limits. CRL becomes a structural engine in your leverage and structured-products stack.
A more detailed version of this roadmap, including risk metrics and P&L breakdowns, is available as part of our gated Risk & Dealer-Hedging materials.
Two ways to deploy CRL
Most pilots start with one of these configurations.
Upgrade existing products
Turn the leverage you already offer into conditional leverage. Until confirmation, the client is linear. After trigger, the whole move from entry is multiplied.
Path for at-risk clients
Move clients statistically close to blow-up into a smarter leverage path — without asking them to stop trading.
Integration, security and operations
From an engineering perspective, CRL is an authenticated API layer and a stateful engine behind it. It is designed to look familiar to teams that already integrate with trading, pricing or risk APIs and to fit into your existing security and monitoring practices, without introducing a new book of record.
Security & reliability by design. CRL is built as a narrow, zero-trust engine behind an authenticated API layer. All traffic is protected with TLS 1.3 and mutual TLS, plus per-request HMAC-SHA256 signing with anti-replay windows. HMAC keys are tenant-scoped and never embedded in the SDK pack; production keys are issued separately and stored in your own secure secret store or KMS, and can be rotated without changing the signing logic.
API surface
The public surface is a small set of REST endpoints for pricing and state updates. Response times in testing are well within typical latency budgets for professional trading environments, so the CRL layer does not add perceptible delay for your clients.
Authentication & transport
Requests are signed with HMAC keys dedicated to each institution and carried over TLS 1.3. For production tenants we support mutual TLS and IP controls on both sides to align with your security policies. The example credentials shipped in the HMAC SDK pack are dummy values for local testing only and are not accepted by any CRL endpoint. Production and sandbox keys are issued under NDA via out-of-band channels, stored in your own secure secret store or KMS, and never embedded in application code.
Monitoring & audit
The engine emits structured audit events and operational metrics that can be pulled into your existing monitoring stack. On top of the database audit trail, CRL runs a cryptographic audit chain: Merkle roots for the audit log are signed through AWS KMS and stored in S3 with WORM retention (COMPLIANCE mode, 7 years). Prometheus exporters allow your risk and internal audit teams to independently verify integrity over time.
A more detailed integration note, together with technical diagrams and sample payloads, is available as part of the gated documentation pack for qualified institutions.
Developer integration and HMAC SDK pack
For institutional developer teams, CRL ships with a small, opinionated integration pack. The engine is exposed as an authenticated REST API with HMAC-signed requests; the SDK pack gives your team a working reference implementation so you do not have to reverse-engineer the signing rules from scratch.
The pack includes a Postman collection and environment for HMAC v1, together
with minimal client stubs in Python, TypeScript/Node.js, Java, C# and Go. Each language
uses the same golden test vector: if your local test reproduces the expected hash and
signature, your implementation is correct. Once you receive real tenant credentials,
a properly signed request will return 201 Created.
The SDK pack includes example credentials that are not valid against any live CRL endpoint. They are provided purely to let developer teams verify their local HMAC implementation against the golden vector without requiring network access or real credentials. Test and production credentials for real tenants are issued separately, under NDA, via secure out-of-band channels and are never shipped inside the SDK pack or public documentation.
The SDK pack contains no production credentials and is safe to share with your internal teams. The
example credentials used for the HMAC v1 golden vector are dummy values that are not
accepted by any CRL endpoint. They exist solely to let your team verify their local HMAC implementation
offline. Production and sandbox keys are issued under NDA via out-of-band channels and must live in
your own secure secret store or KMS, never in application code.
What your developers get
A self-contained archive with a Postman collection, environment, HMAC helper functions, a golden request/response pair and a small test script. It is designed to be read and copied into your existing stack, not to replace your internal SDK conventions. The SDK pack focuses on HMAC authentication and uses a minimal example payload. Product-specific fields such as leverage, triggers and TTL are defined at product level and can be added to the same signed JSON body without changing the signing logic
How integration works in practice
Your team downloads the pack, runs the golden test against our API and then wires the same signing logic into your own pricing or order layer. From there, CRL behaves like any other internal service: authenticated HTTP calls, clear JSON payloads, deterministic responses that you can monitor and log with your current tools.
Scope and eligibility
The SDK pack is provided for institutional use only and assumes a professional development environment (version control, CI, secure secret storage). If you prefer, we can prepare a tenant-specific sandbox and keys for your team as part of a structured pilot process.
Full integration diagrams, tenant provisioning details and operational runbooks are available in the gated documentation pack for qualified institutions.
For Legal, Compliance and Risk
CRL is delivered strictly as a business-to-business calculation engine. We are not a broker-dealer, we do not execute trades, we do not hold client assets and we do not face your end-clients directly.
Your governance
Your institution remains fully responsible for product governance, client classification, suitability, disclosures and regulatory reporting.
Configurable
CRL operates as a configurable software component inside your existing framework. You decide which client segments and instruments may access CRL-based structures.
Evidence-based
All quantitative statements anchored in documented 1M-path Monte Carlo simulation. Stop-out reduction from 43.5% to 3.0% (−93%) in standard 5D configuration.
Full methodology, assumptions and code available in the CRL Quantitative Evidence Report, shared under NDA.
Live System Status
Real-time operational metrics from our production infrastructure. Full transparency on uptime, latency, audit integrity and compliance systems.
Dashboard refreshes automatically every 30 seconds. Open full screen →
See the engine in your own architecture
The most useful conversation is not abstract. It is to look at how CRL would sit next to your current products, platforms and risk views, and what a small, controlled pilot would look like.
