In plain English
Transaction decision proof connects retained payment, authentication, authorization, risk, configuration, human-action, and source-outcome records so a later reviewer can reconstruct what was known and what remains missing. Real time describes the source decision environment. RecordArc remains retrospective, read-only, and off-path; it does not make, rerun, validate, or change the decision.
A simple example
A payment was approved after step-up authentication. Months later, a reviewer needs the payment, authentication, risk, configuration, human-exception and recorded-outcome evidence in one inspectable story.
The payment proof problem
A payment decision can span an orchestration record, an authentication service, an issuer authorization response, a transaction-risk service, configuration registries, and an operations exception workflow. Each system may preserve a valid event while no single record explains the retained path.
The review problem begins after the source decision. A reviewer needs to know which records existed, which versions applied, who exercised authority, which system owned the outcome, and which evidence arrived later.
An eight-part payment decision-proof model
The model follows the source workflow without turning RecordArc into a payment engine or treating chronology as causal correctness.
Payment and fraud-risk decision context
Worked synthetic use case: a step-up payment decision
An illustrative synthetic card-not-present payment receives a step-up authentication response, a retained risk-rule result, an authorization referral, and a later operations exception approval. The owning payment system records the final outcome. RecordArc orders the retained records by timestamp and identifier; it does not invent typed payment-edge semantics.
The retained artifacts are the payment event, authentication response, authorization response, risk result, rule version, threshold version, operations action, and source outcome. A role-delegation record referenced by the approval is unavailable.
Synthetic example
Exception authority remains the proof gap
The record can be reconstructed, but approval authority is not fully evidenced because the role-delegation record is absent.
- Dimension status: Weak.
- Evidence classification: Missing/unverifiable.
- Later-acquired capture data is labelled separately from decision-time evidence.
- The recorded source outcome is preserved, not validated as correct.
What a later reviewer asks
A later reviewer asks whether authentication and authorization responses match the retained payment identity; which risk and configuration versions existed; whether the human exception was within recorded authority; and whether later-acquired evidence has been kept outside the decision-time set.
An audit event may answer when a status changed. The proof record must also expose source ownership, classification, chronology, and the delegation gap without claiming that the source decision should have been different.
What RecordArc reconstructs and does not do
RecordArc reconstructs retained identities, versions, classifications, ordered context, chronology, human authority, proof conditions, and explicit limitations.
RecordArc does not authenticate, authorize, detect fraud, score, route, refer, hold, release, decline, approve, or alter the payment. AML transaction monitoring is a separate Financial Crime & Compliance application of the universal architecture, not part of this payment authorization and fraud-risk path.