Xcelerit Verified Evidence that your numbers are right
Model validation has to show that a pricing library gives the right prices and sensitivities, and what changed in every release. Teams moving code to accelerators have to show the port still matches the original. We produce that evidence at an accuracy agreed before we start, and fix the code where it falls short.
- 3 weeks to under 1Release review at a European bank, evidence pack in 2 days
- Every sensitivityChecked against bumping, risk factor by risk factor
- Since 2012Leading processors benchmarked, method published
Three questions, one method
01 · Model validation
What moved, and why?
Every price and sensitivity that moved between two releases of your pricing library, each tied to the input, constant or code path behind it.
- Dependency map for every price
- Release diff your reviewers can sign off
- For PRA SS1/23, the ECB guide and SR 26-2
02 · AAD
Are the derivatives right?
Every sensitivity checked against bumped or analytic references, risk factor by risk factor, on your own models and inputs.
- Tolerances set with your validation team
- Golden cases frozen and re-run on every change
- Every difference explained, not waved through
03 · Accelerators
Does the port match the reference?
Science, engineering and finance code moved to new processors, checked against the original across inputs, problem sizes and edge cases.
- Operation order, fused arithmetic and compiler settings measured
- Lower precision only where the accuracy budget allows
- The accuracy you can rely on, stated in writing
Every release: what moved, and why.
When your pricing library changes, model validation has to show what changed before it goes live. On XAD-enabled code we report every price and sensitivity that moved between two releases, the cause of each move, and that the sensitivities are right. Reviewers re-check what changed, not everything.
Dependency map
For each price, every input that moves it with its sensitivity, the inputs that have no effect, the hard-coded constants and the branches taken.
Release diff
Two releases side by side: every price and sensitivity that moved, each tied to its cause.
Checked
Every sensitivity in the report checked against bumping, within tolerances set with your validation team.
Runs inside your environment. The dependency map and release diff need XAD in the code; checks against bumping and checks of accelerator ports work on any code. Runs alongside AAD enablement builds and XAD subscriptions, or on its own. Ask for a validation plan.
How a verification runs
Agree the accuracy
A validation plan: what is compared, against which reference, and the tolerance we commit to.
Verify, port or fix
We run the comparison, and move or fix the code where it falls short. You get a report your reviewers can sign off.
Keep it checked
The tests stay with you. When we built the code, your validators hold the tests and re-run them themselves; the evidence never depends on taking our word. If you want, we verify again on every release, and on every new processor, compiler or library version.
Where it has held up
“A release review used to be three weeks of reruns and diffs. Now the evidence pack arrives in two days with every moved price and sensitivity explained, and we sign off within the week.”Head of Model Validation, European bank
Verified · Model validation
A release review from three weeks to under one
Reported by the client · European bank
Release diff for model validation
Every price and sensitivity that moved between two releases of the bank's pricing library, explained in an evidence pack within 2 days: the release review from three weeks to under one.
Full case studyScience and engineering
Large research facility
In production
Reported by the client · Real experimental data · tolerances set by the scientists · checked on every change
Reconstruction that keeps up with the detector
Reconstruction for high-data-rate instruments moved to multi-accelerator clusters. Nothing went live until results matched the reference on real experimental data.
Weather and climate centre
Every field
Reported by the client · Adjoint gradient check · every forecast field · against the CPU reference
Forecast components on accelerators
Dynamical-core and data-assimilation components moved to accelerators, with every field compared with the CPU reference within the science team's thresholds.
Engineering and energy group
100s of cases
Reported by the client · Reference cases passing · on both vendors · on every change
One CFD solver, two accelerator vendors
A production solver written for one accelerator vendor brought to a second for a national supercomputer, with its full validation suite passing on both.
Medical technology company
100s of scans
Reported by the client · Clinical reference · deterministic to the bit · regulatory submission
Clinical-rate image reconstruction
Scanner reconstruction moved from a cluster to one multi-accelerator workstation, validated against the clinical reference and documented for the regulator.
Why we can do this
Distilled from the Xcelerit SDK
For more than a decade the SDK ran one model source on CPUs and accelerators, and the results had to agree on every one. The comparison method and tolerance rules behind that are now a standalone harness that runs on your code as it is, in your language and build, with no SDK needed.
Leading processors benchmarked, published since 2012
A published method, a full record for every run, and results checked on every machine.
Finance BenchmarksThe tests behind XAD
The private validation pack every XAD release passes: derivatives checked against references, release after release.
Verified on the books of banks
Every AAD enablement build ships with a verification suite that runs on the client's own books: every sensitivity checked against bumping, within tolerances agreed with model validation.
How builds are checkedTell us what has to be right
Describe the code, the reference you trust and where it needs to run. We reply with a validation plan.