The VoP Liability Evidence Pack composes two payments nodes: scoring a declared payee-name match under a versioned algorithm, then binding that score, the warning text shown, and the consumer's action into a signed, hash-chained session receipt. This is the workflow a PSP runs at the moment of payment; a separate browser tool later assembles receipts like these into a full reimbursement-claim evidence bundle. Read this before treating a receipt as proof of anything more than what it actually attests.
Stage 1 scores a single declared name pair. Stage 2 consumes that score (or an externally declared score) and produces the receipt a PSP retains as evidence of what happened at the point of payment.
Normalizes a declared payee-name pair (diacritic stripping, legal-entity suffix removal), scores it by integer Levenshtein edit distance against both a plain and a token-sorted form, and bands the result MATCH / CLOSE_MATCH / NO_MATCH against declared thresholds. The algorithm_version travels with the result, so the score is reproducible evidence rather than a black-box vendor output.
Binds the declared match result (Stage 1's score and band, or an external score with a declared source), the warning text and severity shown, and the consumer's action (proceeded, abandoned, retried) across a session's attempts into a signed receipt. Multiple attempts hash-chain to a session-anchored genesis hash, so any reordering or edit breaks the chain. Verifies fully offline.
| The receipt proves | The receipt does NOT prove |
|---|---|
The name-match score and band follow correctly from the declared payee-name pair under the declared algorithm_version. | That the payee named is the real, correct owner of the destination account. |
| That a specific warning text and severity were declared as shown to the consumer, and the consumer's declared action (proceeded, abandoned, retried) at that point. | That the PSP's own interface actually rendered that exact warning — the PSP asserts the display; the receipt binds the assertion. |
| That the sequence of attempts in a session is tamper-evident: reordering or editing any attempt breaks the hash chain from the session-anchored genesis hash. | Who is liable, or how any reimbursement should be split, under any liability regime. |
That a third party can independently replay the computation from the same declared inputs and reach the same execution_hash. | Any opinion, valuation, fault determination, or legal conclusion whatsoever. |
A VoP session receipt is one input to an APP-fraud reimbursement review, not the review itself. The regime that decides what happens next is jurisdiction-specific, and the two named in scheme documentation are not the same kind of rule.
Reimbursement for in-scope APP fraud defaults to a 50/50 split between the sending and receiving PSP, subject to a £85,000 cap, vulnerability adjustments, and a gross-negligence or consumer standard-of-care exception that can remove the customer's entitlement entirely. A VoP session receipt showing a close-match warning was shown and the consumer proceeded anyway is exactly the kind of evidence this review considers — but the split itself is computed by the liability rules, not by the receipt.
Run the split separately with T406 — PSR APP Reimbursement Liability Splitter.
EU IPR made Verification of Payee mandatory for instant credit transfers from October 2025. It is a VoP-availability mandate, not an APP-fraud reimbursement regime — it does not set a liability split. The EU's reimbursement-side analog, under PSD3/the Payment Services Regulation, is forthcoming and not yet in force. Do not treat EU IPR as governing APP reimbursement liability; it governs whether a VoP check happens at all.