ALM and derivatives analytics

Choose ALM Studio when the question starts from the balance sheet: EVE and NII scenarios, IRRBB workflows, banking-book attribution, or committee and reporting needs.

Choose Derivatives Studio when the question starts from the trading book: sensitivity profiles, P&L explain, margin attribution, curve sensitivities, or pre-trade risk.

Yes. The products serve different workflows, but they run on the same analytical foundation: valuation, sensitivities, attribution, and audit trail are produced through the same engine design.

That matters when treasury, ALM, and derivatives teams want consistent methods while keeping their day-to-day workflows separate. Adjoint Algorithmic Differentiation (AAD) is part of that foundation: sensitivities are produced from the same analytical pass that supports attribution and scenario analysis.

A combined deployment should still be scoped by use case; teams can also start with one product and expand later.

Most evaluations start with a benchmark on a representative portfolio. We agree on the questions the team needs to answer first, such as a specific ALM scenario, an attribution view, a margin breakdown, or a sensitivity calculation.

From there, the workflow is built on real, curated, or synthetic data and reviewed against the outputs that matter for the team. The goal is to validate the analytical workflow before deciding production scope.

For ALM Studio, the useful starting point is a representative balance-sheet slice: contract-level cash flows or position data for the books in scope, valuation curves, and assumptions for non-maturity deposits or behavioral models where relevant.

For Derivatives Studio, the useful starting point is trade economics, market data used for pricing, and curve definitions if you want to bring your own. Most evaluations can start from a curated subset, and synthetic portfolios can work when they mirror the dynamics you care about.

No. MASTIX works as an analytical layer alongside existing infrastructure. It can consume positions, contracts, curves, market data, and assumptions from current source systems.

Outputs can be returned through Python, C#, Excel, REST, or connected reporting workflows, so teams can start with one analytical workflow instead of replacing operational systems first.

Model validation can inspect the input snapshot used, the model version and parameter set, the assumptions that were active, and the calculation path that produced each output.

The same calculation chain produces attribution and scenario results, so validation reviews the same analytical path used by the production workflow rather than a separate validation-only reconstruction.

For controlled workflows, a historical result is reproduced by returning to the same input snapshot, market data, curves, model version, parameter set, active assumptions, and calculation configuration.

That is the governance reason for keeping inputs and calculation choices tied to the run, not just storing the final report number. The result can then be traced back through the same calculation chain that produced it.