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. It receives prices and order instructions, maintains a state for each position, and returns the payoffs and settlements of a conditional, retroactive leverage structure that your clients can trade as a product.
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 parameters; the engine returns a full payoff path and a small set of risk / margin metrics. Idempotent endpoints with correlation IDs keep your audit trails clean.
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 compatible with WORM / immutable storage if you require it.
Performance and observability. The engine is deterministic and optimised for low double-digit millisecond latency on typical payloads. Standard metrics for latency, error rates and per-tenant throughput mean your NOC can treat CRL like any other core service.
Tooling. We provide an OpenAPI specification, a Postman collection and example client code so your team can exercise the API on day one. A more opinionated SDK can be added if needed.
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, 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.
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 in the low tens of milliseconds, suitable for professional trading environments without adding perceptible latency to 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, stored in S3 buckets with object-lock/WORM policies and exposed via Prometheus exporters so your risk and internal audit teams can 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 institution remains fully responsible for product governance, client classification, suitability / appropriateness, disclosures and regulatory reporting.
In practice, CRL operates as a configurable software component inside your existing framework and under your own approvals. You decide which client segments and instruments may access CRL-based structures, how they are labelled, and what level of leverage and risk is appropriate for each segment.
Any quantitative statements we make (for example, the 60–75% reduction in early account wipe-outs and the 5–6 month increase in median relationship duration) are anchored in a documented Monte Carlo simulation with clearly stated assumptions and limitations. We apply a conservative haircut to all figures used in external communications, and we provide the full technical note so your risk and model-validation teams can review or reproduce the results.
Full methodology, assumptions and code are available in the CRL Quantitative Evidence Report, shared under NDA as part of the gated documentation pack for qualified institutions.
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.
