A NY Fed Treasury Market Practices Group fails-charge claim is presented once a month by the party that did not fail, to the counterparty that did. It is a bilateral good-faith figure by design: the receiving desk is expected to check the arithmetic before it treats the number as owed. In practice, most desks either take the claim on faith or rebuild the spreadsheet by hand. This pack gives both sides the same one-node recompute to run, so each side reaches its own answer from its own declared inputs, and can hand the other a signed receipt that its own recomputation matched.
Written for dealer settlements staff and back-office operations handling monthly TMPG fails-charge claims on either the claiming or the receiving side.
The pack has a single computational stage. What makes it a bilateral evidence pack rather than a one-sided calculator is who runs it and how the two runs are tied together: the claiming desk runs it once to build the claim, the receiving desk runs it again over the identical declared inputs to check it, and because the kernel is deterministic, an honest recomputation reaches the identical execution hash. Either desk can then countersign a receipt of its own run.
The recompute. You declare a diff tolerance in minor units, never defaulted, and a batch of fails, each with its own fail id, par amount, reference rate in basis points, days failed, and, where you have one to check, a claimed amount. The node applies the published formula, charge equals the greater of zero or three percent minus the reference rate, divided by 360, times par amount, times days failed, rounds to the nearest minor unit, and diffs the result against the claimed amount within your declared tolerance. A fail with no claimed amount cannot be diffed and is reported INDETERMINATE rather than silently passed. Par amounts and claimed amounts are integer minor units, so every comparison is exact integer arithmetic, never a floating-point approximation that could itself explain a small mismatch.
Recomputing the same number twice is only useful if each side can prove, to the other or to a third party, which run it actually did. SPEC.md section 27.12 defines a small, additive record type for exactly that: a counter-signed receipt.
| Step | What happens |
|---|---|
| 1. Claiming desk recomputes | Runs recompute_tmpg_fails_charge over the month's declared fails, seals the resulting artifact, and gets an execution hash. |
| 2. Declared inputs travel | The claiming desk sends the failing counterparty the declared inputs and the sealed artifact, however the two firms already exchange the monthly claim. No relay or registry of AINumbers' sits between them. |
| 3. Failing desk recomputes | Runs the identical node over the identical declared inputs on its own side. A correctly matching recomputation reaches the identical execution hash. |
| 4. Failing desk countersigns | Mints a counter_signed_receipt record: subject_hash names the matched execution hash, kernel_pin names the exact kernel it verified against, role is checker, and replay_verified: true states that it actually re-ran the computation. |
| 5. Either side, or a third party, verifies offline | Recomputes the execution hash from the declared inputs, confirms it matches subject_hash, and checks the receipt's own signature. No connection to either firm's systems is needed. |
The recompute names two distinct subjects and gives each its own verdict from the same three-value vocabulary. The counter-signed receipt names a third, narrower fact and carries no verdict of its own.
| The receipt proves | The receipt does NOT prove |
|---|---|
| That the declared par amounts, reference rates, and days failed, run through the published fails-charge formula and diffed against the declared claimed amounts, produce the recorded per-fail and overall verdicts. | That the declared fails are real, that a settlement fail actually occurred on the declared date, or that the declared reference rate is the market rate that applied. A batch copied from a mistaken spreadsheet matches or diverges exactly as well as a true one. |
| That a counter-signed receipt's signer independently re-ran the identical kernel over the identical declared inputs and reached the identical execution hash. | That either counterparty owes or agrees to the claim, that the matter is closed, or that a later dispute over the underlying fail, its reference rate, or its day count is foreclosed. |
| That a third party can replay the same arithmetic from the same declared inputs and reach the same execution hash, entirely offline, without contacting either firm's systems. | That the fails-charge claim has been paid, that TMPG or the NY Fed endorses this pack, or that any regulatory or market-practice duty has been discharged. |
Carried here as orientation, not restated as facts of our own. Confirm current practice text with the NY Fed Treasury Market Practices Group before relying on any of it for a live claim.
As read on 2026-08-08: the NY Fed Treasury Market Practices Group's fails-charge trading practice (2016 revision) describes a fails charge as a figure the non-defaulting party presents to the failing counterparty for a UST, agency, or agency mortgage-backed security settlement fail, negotiated bilaterally and in good faith between the two desks. This pack produces evidence a desk can hold for that negotiation. It does not source or verify fail status, par amounts, or reference rates from any feed, and it makes no TMPG or NY Fed endorsement claim.
As landed 2026-08-08: SPEC.md section 27.12 adds the counter_signed_receipt record type and the checker role to the existing section 27.2 accountability-record shape, plus two optional sibling fields, kernel_pin and replay_verified. Nothing about the underlying artifact's execution hash, and nothing about any other artifact or record already in the standard, moves as a result.