PRISM / directed translation and information loss
Research settingIndependent
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.
From the research record
Inspect the work
Original figures, recorded values, and explicit model details. Each exhibit identifies its source and what the comparison means.
Where the 512 coordinates go
Scroll horizontally to inspect the full table →
| 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
Read the technical figure
Source: PRISM v0.1 report. Directed rail relationships and 512-dimensional allocation are specified; round-trip diagnostics do not establish payment identity.
Source: PRISM v0.1 report. Directed rail relationships and 512-dimensional allocation are specified; round-trip diagnostics do not establish payment identity.
Supporting detail
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.
Sources, scope, and next question
Versioned build report and deposited working paper; historical performance headlines refer to different records.
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.
- PRISM app.
- PRISM v4.1: Risk-Aware Multi-Rail Payment Reconciliation with Bounded Semantic Translation and Spectral Consensus – Adapting NASA Safety-Critical Systems to Financial Infrastructure.
Additional source versions reviewed
-
prism/docs/REPORT.mdLocal project manuscript or report · not republished here