PRISM: follow one payment across incompatible representations Bee Rosa Davis Research note · Version 0.3 · Updated 8 October 2026 PRISM studies transaction reconciliation across payment rails. Its concrete contribution is a pipeline that keeps matching, translation, consensus, and audit evidence separate enough to inspect where a reconciliation decision came from. TL;DR The question: Can one payment, recorded differently by several payment networks, be matched reliably while keeping each matching decision traceable and its error costs explicit? What the work does: A pure-Python v0.1 pipeline covering five message formats, 512-dimensional block embeddings, hub-and-spoke translators with error bounds, robust amount consensus and hash-sealed decision bundles, tested on generated multi-rail data. What is still open: Matching on real payment records is untested; the report defers real parsers. Ambiguous matches, abstention and costly errors need entity- and time-held-out evaluation. THE RESEARCH IN CONTEXT When money moves between institutions, the same payment is often recorded in several message formats: a SWIFT wire message, an ISO 20022 record, a US ACH batch entry, a card-network ISO 8583 message, or a real-time payment. Reconciliation is the work of confirming that such records describe one transaction. It is difficult because formats carry different fields, names are abbreviated or reordered, fees reduce amounts in transit, dates drift between systems, and some records have no counterpart at all. A wrong match can misstate a balance; a missed match leaves the item in suspense for manual review. The v0.1 build report describes a Python, NumPy and SciPy implementation organized into ingest, embed, select, reconcile, translate, consensus and audit modules, with 235 passing tests across 13 files. Candidate matches come from cross-rail nearest-neighbour search followed by pairwise scoring, with same-rail deduplication and amount and currency consistency filters. Amounts are reconciled with a Huber estimator, which limits the influence of outliers, and each decision is written to a bundle with a SHA-256 Merkle root so that a replay can be checked for identical output. The earlier deposited working paper (October 2025) sets out the broader architecture, including conformal error bounds on translation, tiered consensus, hot, warm and cold replay storage, and regulatory mapping. All evaluation in the report uses a built-in synthetic generator. Its smallest configuration contains 930 transactions: 400 matched groups, 80 orphans with no counterpart and 50 duplicates, perturbed by name variations, date drift of one to three days, fee deductions of 0.1 to 3 percent and paraphrased memos. Results on that set test whether the pipeline recovers the generator's own perturbations; they do not measure performance on real payment populations. The report itself lists real rail parsers, approximate nearest-neighbour indexing and production latency targets as deferred work. AVAILABLE RECORD Versioned build report and deposited working paper; historical performance headlines refer to different records. TECHNICAL FIGURE source-informed technical atlas Source: PRISM v0.1 report. Directed rail relationships and 512-dimensional allocation are specified; round-trip diagnostics do not establish payment identity. Where the 512 coordinates go Implemented representation specification Sub-bundle | Dimensions | Fraction of total | Field treatment in the report Invariant | 256 | 50% | Amount, currency and date hashing Entity | 128 | 25% | Character bigrams Semantic | 96 | 18.75% | One-hot projection Context | 32 | 6.25% | Word hashing The four blocks are combined and L2-normalized. This shows the actual allocation rather than presenting every payment field as interchangeable. Representation dimensions are not matching-accuracy measurements. REPORT.md — Section 2.2 Embedding Space; v0.1 build report What crosses the translation graph The reviewed v0.1 report describes five formats: SWIFT MT103, ISO 20022, NACHA ACH, ISO 8583, and RTP. ISO 20022 is the hub in a directed translation graph. Forward and reverse mappings are separate edges, so a round trip is not assumed to recover information that a format omits. The report divides its 512-dimensional representation into invariant, entity, semantic, and context blocks. Amount, currency, and date play a different role from sender names or free-text memo fields. Candidate retrieval is followed by translation checks, consensus, and a decision bundle with an integrity record. Why an identity check is not a matching-accuracy result The implementation uses normalized embeddings and a sameness/distance identity. Checking that identity can detect an inconsistency in the representation, but it cannot prove that two records describe the same payment. A perfectly valid vector comparison can still match the wrong transaction. The March build report’s precision, recall, and F1 differ from the old website’s production match-rate headline. They are not interchangeable: they refer to different versions and measures, and the report includes a synthetic-data generator. This account retains the implemented architecture without manufacturing a single production accuracy number. THE NEXT RESEARCH STEP The next report should publish the evaluated transaction population, duplicate and unmatched cases, decision thresholds, and review outcomes. The meaningful question is which cross-rail ambiguities the retained structure resolves and which it correctly leaves unmatched. TEACHING CONSTRUCTION (not project measurements) Separate normalization, candidate generation, final matching, and human escalation. Define permitted many-to-one or split-transaction relationships before evaluation. Preserve currency, timestamps, fees, and provenance instead of normalizing away meaningful differences. expected loss = cFP·false matches + cFN·misses + cR·reviews cFP and cFN: Explicit task-specific costs assigned to false matches and misses. Abstention: A deliberate unresolved decision routed for review. Ground truth: The documented reference linking records to underlying transactions. Two same-day payments of the same amount can belong to different customers. Amount-and-date agreement narrows candidates but does not establish identity. A cautious system can defer the ambiguous pair instead of inflating its match rate with an unsupported assignment. SOURCE RECORD PRISM app: https://useprism.sh PRISM v4.1: Risk-Aware Multi-Rail Payment Reconciliation with Bounded Semantic Translation and Spectral Consensus – Adapting NASA Safety-Critical Systems to Financial Infrastructure: https://doi.org/10.5281/zenodo.17489610 local-project/prism/docs/REPORT.md — local source reviewed; not republished Source versions: https://www.davisgeometric.com/research/account-source-records.json No new experiments are reported in this research note. Illustrated study: https://www.davisgeometric.com/research/figures/draft-financial-systems.html