The standard approach to cloud risk: spin up instances, load the pricing library, calibrate, and keep them running. Traders hit the service throughout the day. At night, the instances idle. You pay for 24 hours to use 8.
The problem with always-on
| Metric | Always-On | On-Demand (kernel) |
|---|---|---|
| Utilization | 30-40% | ~100% |
| Cold start | None | <1 second |
| Monthly cost (100 products) | $50K+ | ~$500 |
| Scaling | Pre-provisioned | Automatic |
The 100× cost difference comes from a simple observation: a compiled kernel is a pure function. It has no state, no framework, no library dependencies at runtime. It loads in milliseconds, evaluates in microseconds, and can run on the cheapest serverless infrastructure available.
Binary kernel architecture
- Start of day: Record all pricing kernels. Each becomes a binary blob, a few hundred KB of compiled machine code.
- Deploy: Upload kernels to object storage (S3, GCS). Each kernel is versioned and immutable.
- Evaluate: When a price is needed, a lightweight runtime loads the kernel, sets inputs, calls
forward(), returns the result. The runtime is stateless. It doesn’t know what the kernel computes. - Scale: Each evaluation is independent. Lambda, Cloud Run, or any FaaS platform works. You pay per invocation, not per hour.
Security benefit
The binary kernel contains compiled machine code, not source code. A kernel for an IR swap looks like a kernel for an equity option. Both are opaque binary blobs. This is almost “Enigma-secure”: even if someone obtains the kernel, they cannot reverse-engineer the pricing logic. IP protection comes for free.
Calibration design
Two approaches:
- Calibrate-and-embed: Run the calibration solver, bake the calibrated parameters into the kernel. Each market data snapshot produces a new kernel version. Simple, immutable, auditable.
- Calibrate-on-demand: The kernel accepts model parameters as inputs. A separate calibration service updates parameters when market data moves. More flexible, slightly more complex.
Both work. The choice depends on how frequently your market data changes and how expensive calibration is.
Implemented using AADC, a commercial adjoint AD compiler (matlogica.com).
Frequently Asked Questions
What are the two main approaches to cloud Live Risk and their limitations?
On-demand scaling spawns new instances but introduces latency and resource competition during market turbulence. Always-on approach eliminates latency but is costly, essentially throwing money at the problem. Both are inefficient compared to code generation AAD kernels.
How much faster are AADC kernels compared to original analytics?
AADC binary kernels typically perform 20-50x faster than original analytics due to run-time optimizations and efficient CPU vectorization (AVX2/AVX512). Portfolio risk can be computed in milliseconds with approximately 100x cost reduction.
Are AADC kernels secure for cloud deployment?
Yes, AADC kernels are almost Enigma-secure. They contain only optimized elementary operations with no visibility of original models. Even the same portfolio generates different binary representations each trading day. Proprietary models and trade data remain on premises.
How does AADC handle model calibration in cloud Live Risk?
AADC supports automated Implicit Function Theorem (IFT) enabling fully automated differentiation of exact-fit calibration routines. Calibration can be included in pricing/risk kernels or segregated into separate recordings for consistency across independent calculations.
What is the kernel generation overhead for new trades?
MatLogica uses a specialized graph compiler that generates machine code directly during execution without external compilers. For large portfolios, kernels are generated at start of day and reused. For smaller ad-hoc trades, kernels are generated on-the-fly in seconds.