Attests that a bulk payment run — salaries, pensions, social transfers, vendor payments — is internally consistent and matches its authorization. You supply the authorized control total, the per-payee records (an opaque payee ref, an amount, a rail, a duplicate-candidate key, and optionally a destination-tier balance cap), any declared exclusions, and the prior run's payee-ref summary. This tool checks whether the run reconciles to the authorization in both count and value, surfaces payee refs that share a duplicate-candidate key, reports payees that joined or left versus the prior run, flags limit breaches including a split-payment shape — multiple sub-limit payments to one payee ref summing past a declared limit — and, where a destination-tier cap is declared (§10.2: several retail CBDCs cap a wallet's balance by KYC tier), flags a payment that is authorized and funded but still cannot land because the receiving wallet is at its cap. Emits a hash-anchored OpenChainGraph v0.4 artifact. Region-portable: every fact below is an input you declare, never a hardcoded country, currency, or scheme.
ocg-private-input@1): a bare hash of a payee identifier is NOT safe — identifier spaces are small and structured, so an attacker holding the artifact can precompute the digest of every candidate and recover the plaintext by table lookup. Supply duplicate_key as a sha256-salted@1 commitment — sha256: + the hex SHA-256 of a fresh ≥256-bit secret salt you generate and keep, concatenated with the canonicalized key — and declare the scheme below. The salt never leaves your hands and is never entered here. Declared commitments are listed in the artifact's private_inputs[]; leave the scheme field blank only for legacy runs that predate this contract.The demo figures below are synthetic and already loaded, so you can press Run without entering anything of your own. Load the duplicate/split demo to see the two flags this tool exists to catch.
It does not investigate any payee, does not decide whether a duplicate or split is improper, and does not verify that the figures you supply are complete or accurate — it is an arithmetic attestation over the run you declared. It never accepts or requires a name, account number, or any identifying field, and it never derives the duplicate-candidate key itself — you supply it. Where the prior run's payee-ref summary is not supplied at all, roster movement is reported as unverifiable, never as a false clean. Where a duplicate_key_commitment_scheme is declared, it never sees or asks for the salt or the plaintext behind a commitment — those stay with you.