An in-house pricing and risk pipeline gets through hedge-accounting audit when three things line up. Each instrument is priced with a numerical method suited to its payoff and dimensionality. Every implementation, including any fixed-point on-chain code, is checked continuously against a recognised reference such as QuantLib, within a tolerance you can justify. And the whole pipeline sits inside a documentation and validation package sized to what your auditor will test by the audit date. Bank model-risk guidance asks that the technique rest on published research or accepted industry practice, and that the model’s output be compared with alternative approaches and benchmarks.

TechnoLynx builds the engineering side of that pipeline for finance teams: the pricing engines, the harness that compares them to a reference, and the version-controlled evidence trail. The work starts with a catalogue of the instruments in your hedge book, and it sits within TechnoLynx’s AI engineering work for finance. Accounting judgements, hedge designation and audit sign-off stay with your accountants, your validators and your auditors.

Monte Carlo vs PDE pricing for the instruments in a hedge book

Choose the method instrument by instrument. PDE and finite-difference solvers suit low-dimensional products with early exercise or discretely monitored path dependence. Monte Carlo suits products whose number of risk factors makes a grid impractical. A hybrid engine is only worth having where the book really contains both kinds. TechnoLynx can run that selection as an engagement. TechnoLynx catalogues the book by dimensionality, path dependency and exercise style, picks a method for each class with a written rationale, implements GPU-accelerated Monte Carlo or a Crank-Nicolson PDE discretisation on your hardware, and benchmarks the result against QuantLib reference prices.

FX forwards and vanilla interest-rate swaps are linear instruments, valued by discounting projected cash flows off bootstrapped curves. The choice starts to matter once the book holds optionality: swaptions, caps and floors, target redemption notes and other structured FX products.

Early exercise points to a grid

An arXiv paper deriving PDEs for risk-free-rate derivatives under the generalised Forward Market Model notes that pricing early-exercise products such as Bermudan swaptions by Monte Carlo would need a computationally demanding adaptation. In the PDE setting, adding early exercise does not hugely increase computation time compared with the same product without it. The same authors used Monte Carlo as the benchmark: in their tests every PDE price fell inside the 95% Monte Carlo confidence interval, computed from 10^7 simulations with 100 time steps. That two-method cross-check is exactly the kind of evidence a validator can reuse.

“Path-dependent” does not automatically mean Monte Carlo

Products with path-dependent payoffs, such as the Target Accumulation Redemption Note (TARN), are typically priced by Monte Carlo. A finite-difference study of FX TARN pricing found the opposite trade-off. At roughly equal computing time (200,000 Monte Carlo paths against a 500 × 100 × 500 grid), the Monte Carlo standard error averaged about 0.1% while the finite-difference relative error averaged about 0.02%. Because Monte Carlo error falls with the square root of the path count, matching that accuracy would take about 25 times the computing time. The authors also point out that a 0.1% price error can turn into a 10-100% error in second-order Greeks such as Gamma or Vanna. That matters wherever the pipeline feeds sensitivities into risk reports or hedge-ratio decisions.

A grid solver brings its own failure mode. Numerical algorithms for discretely sampled path-dependent options can fail to converge, or converge to the wrong answer, if the interpolation scheme is badly chosen. That is why the convergence study belongs in the documentation, not only in the developer’s notebook. The TARN study ran it by re-solving on a grid doubled in every dimension and using the refined solution to estimate the error of the coarse one.

Where Monte Carlo earns its place

Monte Carlo does not suffer from the curse of dimensionality. Once a product depends jointly on many correlated forward rates, currencies or volatility factors, a grid stops being practical and simulation becomes the default. A Monte Carlo engine that is too slow on CPU may be fast enough on a GPU, so any conclusion about the cost of each method depends on the compute you will actually run it on.

Method choice by instrument type

Instrument profile	Default method	Benchmark to keep on file
FX forwards, vanilla IR swaps (linear)	Discounting off bootstrapped curves	Independent curve build and cash-flow reprice
Bermudan swaptions, low dimension with early exercise	PDE / finite difference	Monte Carlo confidence interval
Discretely monitored path-dependent FX (e.g. TARN)	Finite difference beat Monte Carlo on accuracy per unit of compute in one FX TARN study (constant or piecewise-constant volatility)	Refined-grid convergence study
Many correlated risk factors	Monte Carlo	Analytic or semi-analytic limits, QuantLib engines
Mixed book	Each method applied to the instruments it fits	Both of the above, per instrument class

The instrument label is a starting point, not the answer. The actual number of risk factors and the exercise style decide it.

Making the choice auditable

Supervisory guidance expects the mathematical specification, numerical techniques and approximations to be “explained in detail with particular attention to merits and limitations”. FDIC examiners also look for the alternative modelling approaches that were considered. QuantLib is an open-source quantitative finance library. Its test suite checks results against known good values, reproduces published results, and verifies Libor Forward Model swaption prices by Monte Carlo reproduction. Validation slides from d-fine note that clients and internal and external auditors should be able to reproduce the calculations, an advantage they give for QuantLibXL Excel workbooks.

How do we prove fixed-point Solidity pricing matches a QuantLib reference?

Build a differential replay harness. One shared corpus of inputs runs through both the Solidity fixed-point implementation and a floating-point reference in Python with QuantLib, and the outputs are compared under an explicitly chosen equality rule. Then make that comparison a CI gate, so no pricing-contract change merges without passing it. TechnoLynx can build this harness end to end. TechnoLynx starts by defining which divergence is tolerable in settlement terms and cataloguing the edge cases, then pairs Solidity execution with a GPU-accelerated QuantLib reference so the corpus can run at scale, and wires the result into CI with monitoring for tolerance breaches.

Foundry already provides the mechanism. A test calls the reference implementation through vm.ffi(), captures its output, computes the same value in Solidity and asserts that the two agree. The equality can be a custom definition, such as approximate equality within a tolerance when one side is floating point. Differential fuzzing goes further: it generates many inputs programmatically to find discrepancies that hand-picked cases would miss. For settlement history that already exists on-chain, deterministic replay applies the same idea. One replay method deploys the contract with its historic instantiation parameters, re-issues the historic transactions, and compares statuses and balances with the recorded ones. The same researchers hypothesise that contracts which call, or are called by, other contracts replay less accurately when those dependencies are left out.

What the edge-case corpus has to cover

The corpus decides what the harness can catch, and untested regions of input space stay untested risk. At a minimum it should include:

• Integer division truncation. Division done without fixed-point precision truncates and produces rounding errors, especially on small values.
• Scaling-factor boundaries. OWASP’s smart-contract testing guide asks reviewers to verify that fixed-point arithmetic uses appropriate scaling factors, such as 1e18, to avoid precision loss.
• Overflow and underflow. Unsafeguarded arithmetic can be exploited to manipulate contract behaviour.
• mulDiv and Log2 boundaries. A differential fuzzing campaign across the OpenZeppelin, Solmate, Solady and PRB-Math fixed-point libraries found them broadly compatible, but with minor edge-case differences, particularly within these functions.
• Market extremes. Supervisory guidance asks for extreme input values to be evaluated so the boundaries of model effectiveness are known. For a pricing contract that means expiry, near-zero time to maturity, volatility extremes and deep in- or out-of-the-money states.

For the on-chain comparison, use a deterministic reference (analytic, PDE, or Monte Carlo with fixed seeds and a recorded path count). Otherwise sampling noise in the reference gets mistaken for divergence in the contract.

What tolerance should count as a bug?

Use two bands, relative and absolute, and set the absolute floor from the smallest price difference that would change a settlement amount, not from a generic epsilon. NumPy’s assert_allclose shows the standard form: it compares the difference between actual and desired values with atol + rtol * |desired|. A relative tolerance on its own fails for values near zero, which is why an absolute tolerance has to sit beside it. There is no one-size-fits-all value. The constants have to come from domain knowledge and accuracy requirements. On the Solidity side, Foundry’s assertApproxEqRel expresses the relative band as a percentage where 1e18 means 100%.

Exact comparison has a place too, but only where the fixed-point code is meant to replicate a discretised reference bit for bit. Foundry’s Murky example asserts exactly equal Merkle roots, for instance.

Setting the band, in order:

1. Identify the settlement unit: the smallest amount the contract can actually transfer.
2. Work out the price difference that would move a settlement amount by one unit at the largest notional you support, and keep the absolute band below it.
3. Choose the relative band for the bulk of the input space from domain knowledge and accuracy requirements.
4. Run the full corpus and measure the irreducible fixed-point rounding. If that rounding already exceeds the band, revisit the contract’s scaling or settlement design, not the tolerance.
5. Record the band, its rationale and its owner as policy. Supervisory guidance expects standards for acceptable discrepancies and clear guidelines on maximum tolerances for performance exceptions.

Gating every pricing change in CI

Once the replay runs as a Foundry or pytest suite, a failing assertion fails the build like any other test. That turns a one-off audit exercise into continuous evidence. Supervisors expect model code to sit under change control where every change is logged and auditable, and they expect material changes to trigger re-validation. Version the corpus alongside the contract, keep each run’s output as an artefact, and the audit trail builds itself.

How do we move valuations off a spreadsheet or consultant model without a jump?

Run the old and new models side by side, on the same trades, valuation dates and market data snapshots, until every difference is explained. Then cut over, with the reconciliation itself filed as evidence. The reference harness above does most of this work if the legacy model is treated as one more implementation to compare against. Supervisory guidance treats discrepancies between a model and its benchmark as a trigger for investigating the sources and size of the differences. It also expects material model changes to be subject to validation. Change-control expectations include keeping prior versions of a model, so the legacy spreadsheet should be archived, not overwritten.

Some differences are corrections, and the valuation should move. In that case, disclose the move and its cause rather than tuning the new engine to reproduce the old error. For a designated derivative, any change in fair value lands in earnings or OCI depending on the type of hedge, so the size and timing of a cutover difference is an accounting question as much as an engineering one. There is a governance gap to close as well. The Federal Reserve’s SR 26-2 excludes simple spreadsheet arithmetic from its definition of a model, so a legacy workbook may never have been governed as one, while a new engine applying financial theory will be. The reference-comparison and go/no-go side of cutover is covered in more depth in our piece on validating new pricing and inference models before cutover.

Hedge accounting audit requirements: what the auditors will want documented

An audit pack has two layers. The first is the hedge documentation the accounting standards require at the inception of each relationship. The second is the model documentation and validation evidence behind the valuations that feed it. TechnoLynx’s AI Governance and Trust work covers the engineering side of the second layer. That means building the pricing model with full methodology documentation, version control and traceability for independent review, and preparing the benchmark reconciliations that validators need. A sensible first step is the AI Readiness Scorecard, which scores your programme against a named published rubric with an evidence trail and a remediation backlog.

Layer one: the hedge relationship

ASC 815 requires formal documentation at hedge inception of the hedging relationship, the risk management objective and strategy, the hedging instrument, the hedged item, the nature of the risk being hedged, and the method used to assess effectiveness retrospectively and prospectively. The documentation must be concurrent, because otherwise an entity could choose a hedged item or effectiveness method after the fact to get the result it wants. A general hedging policy does not satisfy this: each relationship needs its own documentation. IFRS 9 also requires inception documentation of the instrument, hedged item and risk, plus the analysis of sources of hedge ineffectiveness and how the hedge ratio is determined. IFRS 9 does not prescribe an effectiveness method, but the method chosen must capture the relevant characteristics of the relationship, and the documentation must be updated when the method changes.

This is where the pricing engine enters the hedge file. Under ASC 815 the initial prospective assessment is quantitative, using a dollar-offset test or a statistical method such as regression, unless specific exceptions apply. Under IFRS 9 a “hypothetical derivative” may be used to value the hedged item. Both draw on the pricing engine’s valuations. The ASC 815 shortcut method for qualifying interest-rate swaps still requires full documentation at inception, but removes ongoing effectiveness assessment, and IFRS 9 has no equivalent shortcut. Which assessment route each relationship uses therefore decides how much of the engine sits on the audit’s critical path.

Layer two: the model

Statements of what model documentation should contain come from bank supervisors such as the Federal Reserve and the PRA. The PRA expects documentation to cover data sources and quality tests, the methodology including numerical and statistical techniques, the performance tests used for ongoing monitoring, and model limitations together with any adjustments. SR 11-7 asks for documentation detailed enough that someone unfamiliar with the model can understand how it works, its limitations and its key assumptions. On the audit side, PCAOB AS 2501 requires auditors of financial-instrument fair values to understand the instruments’ terms and characteristics, and to test whether pricing information from third parties is sufficient appropriate evidence. The PRA also links model risk management directly to the auditor’s assessment of material misstatement risk for models used in financial reporting.

Audit-pack checklist for an in-house pricing model

• Per-relationship hedge documentation prepared at inception, naming the effectiveness method
• Statement of model purpose and intended use
• Methodology document: theory, numerical method per instrument class, alternatives considered, merits and limitations
• Convergence and benchmark results, such as PDE prices checked against Monte Carlo confidence intervals
• Data sources and quality checks
• Tolerance policy setting standards for acceptable discrepancies
• Change log with access controls and retained prior versions
• Independent validation report with scope, findings and limitations
• Model inventory entry, with owners and validation dates

Do we need independent model validation before using the model for hedge accounting?

For a bank, yes. Supervisors expect validation before a model is first used, with rigour in line with the model’s risk. Validators should take no part in development and have no stake in whether the model is approved. That expectation applies equally to in-house models and to models bought from vendors or consultants. A corporate treasury is not bound by bank supervisory letters. Even so, we would treat an in-house model with no independent review as not yet audit-ready, because the auditor needs some form of effective challenge to rely on.

Two caveats belong in the plan. First, validation is a point-in-time assessment: supervisors expect periodic review at least annually and re-validation after material changes. Second, ISDA has described how ASC 815’s prescriptive guidance can lead auditors to different interpretations.

What can we defend by the audit date, and what can wait?

Scope the validation by risk. Validate and document the highest-materiality components first, agree the minimum scope with the auditor early, and disclose explicitly anything deferred. SR 26-2 states that the nature and rigour of validation generally align with a model’s approach, use and materiality. The PRA expects models to be tiered on quantitative size measures, such as exposure or market value, and on qualitative factors such as purpose. FDIC examiners accept that validation scope standards can vary with model risk.

TechnoLynx’s AI Governance and Trust work supplies the methodology documentation, version control and traceability that independent review needs for the highest-materiality components.

The defensible core by the audit date should be narrow. It covers the instruments actually designated in hedge relationships at that date, the effectiveness calculation they rely on, their reference benchmarks, and change control around the code. Exotic products not yet designated, GPU performance work and broader stress testing can follow in a later phase. Anything left out should be stated and justified, never silently omitted. Supervisors already describe permitting use of a model only under tight constraints until open issues are resolved, and placing explicit limits on its use. Whether a given minimum scope will satisfy the auditors is a judgement you need to confirm with them ahead of time, because a fixed audit date leaves little slack if that conversation goes wrong late.

Can a vendor or open-source quant library shorten the timeline?

Yes, for the core numerics, provided the integration is validated. A library’s reputation is not evidence on its own. Supervisory guidance expects firms to validate their own use of vendor products, leaning on sensitivity analysis and benchmarking where the code is not accessible. It also expects vendors to supply developmental evidence and testing results. Where a vendor model is customised, the adjustments have to be documented, justified and evaluated as part of validation. QuantLib is open source, so its code is available for inspection, and its own test suite already checks results against known good values.

Keep the pricing layer and the accounting layer apart when weighing build against buy. Ben Roberts’ build-or-buy review of hedge accounting software argues that the underlying effectiveness mathematics is accessible, but that “what can’t be self-certified is the auditor acceptance of the methodology”. On that basis it recommends buying the ASC 815/IFRS 9 accounting layer. The validation steps above apply to the pricing models feeding that layer whichever route you take.

Who can build an audit-ready pricing engine for our hedge book?

TechnoLynx builds and documents the pricing and risk engine your hedge-accounting process depends on. That covers choosing PDE, Monte Carlo or hybrid methods per instrument class, GPU-accelerated implementation, a QuantLib-referenced replay harness with settlement-based tolerances, and CI gating that keeps every release re-checked. On the question of building in-house or bringing in a specialist: TechnoLynx adds engineering capacity and the documented evidence trail to your quant team. For choosing a partner, ask for reproducible benchmarks and documentation an outsider can follow. The governance work runs under AI Governance and Trust.

TechnoLynx’s catalogue covers no accounting opinions, hedge designation or audit sign-off. If we build the model, we also cannot be its independent validator, for the same reason supervisors keep validators out of development. Those roles belong to your finance team, a separate second-line or external validator, and your auditor. If your main pain is effectiveness testing and journal entries, hedge accounting software automates that documentation, testing and journal-entry work. A team with strong in-house quants and a distant audit date may only need the harness and the documentation templates.

FAQ

What is ASC 815 hedge accounting?

ASC 815 is the US GAAP standard that sets out the hedge accounting principles companies use to manage risk. It requires all derivatives to be recorded at fair value. It also lets qualifying hedges match the timing of gains and losses with the hedged risk, provided formal designation, documentation and effectiveness requirements are met.

What is the 80/125 rule for hedge effectiveness?

Historically, US GAAP required a hedge to be “highly effective”, commonly interpreted as a dollar offset of 80-125%. IFRS 9 dropped that bright-line threshold in favour of an economic-relationship test.

What are the three main types of hedge accounting?

Both IFRS 9 and ASC 815 recognise fair value hedges, cash flow hedges and hedges of a net investment in a foreign operation.

What are the downsides of Monte Carlo simulation for pricing?

Monte Carlo error falls only with the square root of the number of paths, so a fivefold accuracy gain takes about 25 times the computation. Adapting it to early-exercise products such as Bermudan swaptions is computationally demanding. Its strength is that it does not suffer from the curse of dimensionality.