Optional patterns for production live risk systems. Use what works for you.
This page covers advanced architecture patterns. If you're just getting started, see our simpler Integration Guide.
You've already integrated AADC and now you're asking:
Many customers run AADC successfully without any of this. But if you're building a production live risk system, these patterns will save you months of trial and error.
AADC records whatever function you execute. If you call `price_portfolio()`, that becomes a kernel. If you call `calibrate_curves()`, that's another kernel.
This blueprint answers: 'What functions do successful live risk implementations typically record?' It's not a requirement — it's a collection of what works.
Most customers start with a single kernel and expand organically. The architecture emerges from your actual workflows, not from upfront planning.
Here's what successful implementations typically look like — not what you must do
AADC records whatever function you execute—no upfront planning required. As your usage grows, you'll naturally develop patterns that work for your workflow. Many teams end up with separate kernels for curve calibration, portfolio pricing, and risk sensitivities, but this emerges organically from actual use.
Most teams record curve-building as a separate kernel. Why? Because curves change less frequently than portfolios.
Typical: Generated once per day or on significant market moves
Record your portfolio pricing once, execute thousands of times with different market data throughout the day.
Typical: Recorded at start of day, reused for every price update
Greeks come automatically via the adjoint pass. Some teams combine pricing and risk; others keep them separate.
Typical: Often integrated with pricing, sometimes separate for flexibility
A typical day with AADC kernels
Here's how production teams typically structure their day. This isn't a requirement — just a common pattern.
Generate calibration kernels from overnight data. These run fast enough that you can recalibrate whenever curves move significantly.
Record portfolio pricing kernels for the day's positions. New trades added during the day can extend existing kernels.
Execute pre-recorded kernels with live market data. Sub-millisecond updates. No re-recording needed for market moves.
Standard trades use pre-recorded kernels (sub-millisecond). Bespoke trades get recorded on-the-fly (seconds, then cached).
One of AADC's key advantages
You don't need to regenerate kernels when trades change. Use scaling factors to add, remove, or modify trades in place.
Append new trades to existing kernels. The kernel structure accommodates new positions without full regeneration.
How: New trade inherits kernel structure; scaling factor starts at 1.0
Set a trade's scaling factor to zero. The kernel still runs; that trade simply contributes nothing.
How: Scaling factor → 0 removes contribution; kernel remains valid
Reduce position size by adjusting the scaling factor. Half the position? Set scaling to 0.5.
How: Scaling factor 0-1 for proportional position changes
Many parameter changes don't require re-recording at all. Market inputs can be updated directly.
How: Input parameters can be changed without touching the kernel
Same kernels, different inputs
Once you have a kernel, scenario analysis is essentially free. Apply different market conditions to see the impact.
Run the same kernel with stressed market inputs. What happens if rates move 100bp? Same kernel, different inputs, instant answer.
Combine scaling factors with scenarios. 'What if we added this trade AND rates moved 50bp?' Handled in milliseconds.
Run regulatory stress scenarios across the entire portfolio. The kernel handles thousands of scenarios without re-recording.
Binary kernels run anywhere
AADC compiles your models to binary kernels — optimized machine code that runs 6-1000x faster. These kernels are portable.
Run entirely within your infrastructure. Full control, no external dependencies.
Best for: Regulated environments, latency-sensitive applications
Deploy encrypted kernels to AWS, Azure, GCP. Your models stay on-premises; only compiled binaries move to cloud.
Best for: Scalability, cost optimization, burst capacity
Record on-premises where your IP lives. Execute in cloud when you need scale. Best of both worlds.
Best for: Most production deployments
Record once on-premises where your proprietary models live. Deploy kernels anywhere — cloud, edge, multi-region. Your IP never leaves your secure environment.
Sub-millisecond pricing for standard trades
Trade changes without kernel rebuilds
All sensitivities in single pass
From single desk to enterprise-wide
We can help you plan the architecture that fits your specific needs — or just answer questions about what's worked for others.