Assuming System P&L means the official end-of-day valuation and Trader P&L means the desk’s estimate or trader-marked view, I would model the following six root-cause families.

The ranking is a practical investigation order, not an industry-wide statistical ranking.

RankUnderlying factorTypical examplesExpected signature
1Position and lifecycle populationMissing new trade, late amendment, cancellation, novation, termination, allocation, wrong bookWhole-trade or large discrete difference
2Market-data snapshot and timingTrader uses 4 p.m.; system uses later EOD snapshot; stale or missing quoteDifference correlates with intraday market move
3Curves and valuation inputsDifferent projection/discount curves, CSA discounting, interpolation, spread or FX curveDifference concentrated by currency, curve or tenor
4Trade economics and static dataWrong notional, rate, dates, index, frequency, day count, calendar or pay/receive directionPersistent trade-level difference
5Fixings, cash flows and accrual treatmentMissing fixing, estimated versus published fixing, payment timing, accrued interest, feesDifference around reset/payment dates
6P&L methodology and scopeDifferent prior-day baseline, realized versus unrealized treatment, carry, new-deal P&L, reserves, FX translation or roundingValuations may agree while reported P&L does not

CFTC reconciliation guidance explicitly distinguishes discrepancies in a swap’s material terms from discrepancies in its valuation, and includes lifecycle events such as amendments, novations and terminations in the recordkeeping context. That supports investigating population and economics before assuming a pricing-model problem. CFTC portfolio-reconciliation rule

CME’s operational reports similarly separate open/new trades and cash flows from curve inputs and discount factors, which is a useful blueprint for the reconciliation categories. CME cleared-IRS reports

1. Position and lifecycle population

First determine whether both calculations valued the same population:

cause(Trade, missing_from_system) :-
    trader_trade(Trade),
    not system_trade(Trade).

cause(Trade, lifecycle_mismatch) :-
    trader_status(Trade, TraderStatus),
    system_status(Trade, SystemStatus),
    TraderStatus != SystemStatus.

Check:

This should usually be checked first because there is little value comparing valuations until both sides contain the same trades.

2. Market-data snapshot and timing

The trader may calculate an intraday estimate using live prices while the system uses an official closing snapshot:

cause(Trade, market_data_timing) :-
    trader_snapshot(Trade, TraderTime),
    system_snapshot(Trade, SystemTime),
    TraderTime != SystemTime.

This includes:

Settlement systems explicitly take price and position snapshots at defined settlement cycles, so timing is part of the valuation specification—not merely operational metadata. CME settlement overview

3. Curves and valuation inputs

Even at the same timestamp, the sides might use different:

CME documents that its IRS curves depend on input instruments, multiple quote sources, validation, bootstrapping and interpolation. Any difference in these choices can produce a swap valuation break, especially at concentrated tenors. CME IRS curve methodology

Useful rules could be:

cause(Trade, discount_curve_mismatch) :-
    trader_discount_curve(Trade, A),
    system_discount_curve(Trade, B),
    A != B.

cause(Trade, curve_version_mismatch) :-
    trader_curve_version(Trade, A),
    system_curve_version(Trade, B),
    A != B.

4. Trade economics and static data

Both sides may contain a trade with the same identifier while valuing materially different economics:

economic_term(Trade, notional, Value).
economic_term(Trade, fixed_rate, Value).
economic_term(Trade, maturity_date, Value).

Relevant fields include:

For explainability, compare the normalized economic terms field by field rather than reducing everything to a generic trade_mismatch.

5. Fixings, cash flows and accruals

This category is especially important for swaps near reset and payment dates:

cause(Trade, fixing_mismatch, Index, Date) :-
    trader_fixing(Trade, Index, Date, A),
    system_fixing(Trade, Index, Date, B),
    A != B.

Common causes are:

6. P&L methodology and scope

The two sides can agree on today’s valuation but disagree on P&L:

System P&L = System valuation today − System valuation yesterday
Trader P&L = Trader valuation today − Trader valuation yesterday

If yesterday’s baselines differ, today’s P&L differs even when today’s valuations match.

Compare treatment of:

Best investigation sequence

For the PoC, the LLM should evaluate the causes in this order:

Same population?
    ↓ yes
Same economic terms and lifecycle state?
    ↓ yes
Same valuation timestamp and market-data versions?
    ↓ yes
Same curves and pricing configuration?
    ↓ yes
Same fixings, cash flows and accrual state?
    ↓ yes
Same P&L baseline, scope and accounting convention?