Binding ISO 20022 credit transfer initiations to an approved order: how often transactions in published files carry a structured reference

Few transactions in pain.001 files returned by one capped GitHub code search and one repository, one of which holds 85.6% of the transactions, carry a structured reference to a document. Of 2,647 transactions in 221 parsed pain.001 files from 89 of 94 GitHub repositories, whose transactions come from 84, 61 (2.3%) carry a referred-document number or a creditor reference, 77 carry a structured remittance block with neither, 2,394 carry only unstructured text and 115 carry no remittance information. Without one repository, called repository D, whose files may be real bank instructions and which holds 28 of the 61, 33 of 2,556 transactions (1.3%) carry one, a figure computed after the run, outside the protocol. Field length does not prevent it. Whether schemes, banks and intermediaries accept, preserve and route the reference is not tested here. An order's 64-character SHA-256 identifier fits in the 140-character additional remittance information, and its 128-bit truncation, written as 32 hexadecimal characters, fits in the 35-character referred-document number with the document type code for a purchase order. The paper also specifies a pre-authorization control that admits a payment instruction only within a limit built from the order record a person signed, including a running total across payments, and a record specified so that each decision can be recomputed, which was not evaluated. In a harness-mediated function test on orders built from the 60 eligible transactions, the control's code admitted all 60 instructions carrying the transaction's own amount and currency, with amounts taken at their own decimal scale, which may differ from the ISO 4217 minor unit, and refused every instruction one unit of the amount's own last decimal place over at the exact tolerance, a second instruction by the running total (the duplicate rule was not exercised), and every altered reference, refused by the harness's map by construction. A first run, the only one inside the stop rule, built every order in USD and refused 27 of 60 for currency mismatch. The caveats are these. Each order was built from its own transaction, so the simulation says nothing about orders a person approved. A harness, not the control, mapped each reference to its order, so the altered references were refused by construction. For 19 admissions, all in repository D, the payee was a placeholder. One repository holds 2,265 of the 2,647 transactions. The second and third runs of the simulation, a per-repository tally and the placeholder count fall outside the protocol's stop rule. The unwinding of reversals, delegation and a sequential test of published rates are specified and not evaluated. © 2026 Salvatore Ciaravino. This work is licensed under the Creative Commons Attribution 4.0 International License (CC BY 4.0), https://creativecommons.org/licenses/by/4.0/. Revision 7. This version: DOI 10.5281/zenodo.23424266. It revises the version posted as DOI 10.5281/zenodo.23406944 in response to review reports produced with AI review tools, not by human peer reviewers. Every change is listed in the corrections table deposited with this version.