Short answer
Transaction decision proof connects the retained records around banking and payment decisions so authorized reviewers can understand what happened, which evidence and versions were available, where people intervened, and what remains missing. RecordArc performs that reconstruction retrospectively through a read-only Decision Proof Layer; it does not make, rerun, validate, or alter the source decision.
Why proof fragments across banking and payment systems
A single transaction can leave separate records across payment orchestration, authentication, authorization, risk, merchant or acquiring platforms, configuration registries, operational exception workflows and human approvals.
Each system can remain authoritative for its own recorded state while a later reviewer still lacks one connected chronology. Transaction decision proof addresses that review problem without moving the source decision into a new engine.
What retained context can be reconstructed
The reconstruction may connect the transaction event, authentication and authorization responses, risk or rule context, policy and configuration versions, referrals, holds, retries, overrides, human actions and the final recorded source outcome.
Those are source-system contexts and recorded outcomes. RecordArc does not authenticate, authorize, score, route, refer, hold, release, approve or decline a transaction.
Cross-system proof context
What real-time means here
Real-time describes the source banking and payment decision environment being proved. RecordArc remains off-path, retrospective, read-only and non-authoritative for source business state.
Deterministic proof does not depend on a live AI runtime. Any future AI assistance remains bounded, explain-only, traceable and non-authoritative.
Why AML transaction monitoring is one scenario
AML transaction monitoring is a Financial Crime use case within the broader transaction-decision proof wedge. Its alert, investigation, analyst, approval and closure records demonstrate the same source, chronology, authority and limitation disciplines in a specific workflow.
The public AML record remains useful, but it does not define the full category or imply that every banking and payment decision is an AML alert.
Synthetic example
Two distinct public proof paths
The flagship Lab record shows cross-system payment decision context. The separate AML example shows a synthetic alert review and recorded closure.
- Flagship: banking and payment transaction-decision reconstruction.
- Public AML example: transaction-monitoring alert review.
- Both remain synthetic, read-only and non-authoritative.
How a bounded evaluation can be framed
A useful evaluation begins with one review question and a defined source scope. It examines reconstruction coverage, evidence-gap coverage, version linkage, chronology coverage, approval or exception-chain coverage, review-package consistency and the source effort required to answer the question.
These are evaluation dimensions, not promised results or universal performance targets.