Most asset-liability management (ALM) platforms produce economic value of equity (EVE), net interest income (NII), and interest-rate risk in the banking book (IRRBB) outputs. Architecture matters when a user asks why a number moved, changes an assumption, or runs another scenario.
Batch processing remains appropriate for large or tightly controlled production workloads. It should not prevent treasury teams from investigating results while a decision is still active.
Four properties of an effective ALM architecture
1. A bottom-up analytical foundation
A bottom-up ALM architecture starts with individual contracts. Cash flows are projected at instrument level and then aggregated into portfolio and balance-sheet views. This preserves the link from a reported result back to the positions, assumptions, and cash flows that produced it.
EVE, NII, scenarios, sensitivities, and attribution reuse this foundation while retaining their own horizons, assumptions, and aggregation rules.
When metrics differ, teams can trace the difference to its assumptions or definition instead of first reconciling unrelated calculation chains.
2. Performance matched to the workload
Performance claims need a defined portfolio, scenario set, output scope, and hardware environment.
In MASTIX ALM workflows, what-if analysis on a prepared portfolio state—such as rate shocks and assumption changes—can run in seconds. Broader balance-sheet scenarios with the core metrics required for decision support can run in minutes instead of overnight.
These timings do not include every downstream report or regulatory artifact. They allow analysts to test and compare alternatives during the working session.
3. Sensitivities without factor-by-factor reruns
Adjoint algorithmic differentiation (AAD) differentiates the implemented valuation and projection logic. It produces configured first-order sensitivities across the modeled instruments in a calculation without a separate finite-difference rerun for each factor.
The sensitivities are model-consistent, not model-free. Coverage depends on the implemented models, assumptions, numerical logic, and configured risk factors.
Fewer reruns reduce processing time and limit opportunities for inconsistent inputs. The sensitivities also remain connected to the calculation that produced the base result.
4. Explanation tied to the calculation
Attribution is easier to review when contracts, market data, behavioral assumptions, cash flows, and reported outputs remain linked.
Configured explanations may cover market movements, new business, portfolio changes, runoff, and model or assumption changes. Any residual remains visible rather than being hidden by the decomposition.
Excel, Python, and API workflows should call the same controlled analytical services. Otherwise, each interface risks becoming a separate implementation of the methodology.
What changes in practice
Analysts can test scenarios during a discussion instead of moving every follow-up question into another production cycle. Treasury can assess a proposed balance-sheet action, review its effect on EVE and NII, and test a revised assumption using the same analytical foundation.
Calculation lineage also supports governance. An asset-liability committee (ALCO), model-validation team, or auditor can inspect the input version, assumptions, model configuration, contract-level contributions, and drivers behind a result.
Approvals, access controls, change management, and reconciliation remain necessary. A shared architecture makes differences easier to locate and explain.
What to evaluate
A platform evaluation should test the calculation architecture as well as the interface.
- Define the workload. Record the portfolio, instruments, scenarios, risk factors, metrics, output detail, hardware, concurrency, and data-loading scope.
- Test coverage. Map instruments, optionality, behavioral assumptions, currencies, curves, and risk factors to implemented functionality.
- Identify what is shared. Verify where EVE, NII, scenarios, sensitivities, and attribution reuse projections and where their methods differ.
- Inspect sensitivity methods. Confirm which measures use AAD and how the platform handles discontinuities or non-differentiable model features.
- Trace and reproduce a result. Retain inputs, software and model versions, configuration, and an agreed numerical tolerance.
- Test operating controls. Confirm that Excel, Python, and API workflows preserve permissions, configuration, logging, failure handling, and approvals.
MASTIX ALM Studio architecture
MASTIX ALM Studio uses contract-level projections and a shared analytical implementation for core balance-sheet metrics, scenarios, sensitivities, and attribution.
Within supported instrument models and configured risk factors, AAD produces model-consistent sensitivities without one finite-difference rerun per factor. Teams access the same analytical platform through Excel, Python, and APIs for investigation and controlled production use.
Teams can move from a reported number to the contracts, assumptions, and calculations behind it.