Agent Payments Need a Decision Receipt

A Decision Receipt is not a transaction receipt

A transaction receipt or payment confirmation tells you something about what happened on a payment rail or at a provider. A Decision Receipt answers an earlier question: why was this exact candidate allowed, escalated, or denied under the technical authority and policy state represented by the system at that moment?

It should not become a full agent transcript either. A reviewer usually does not need every prompt, model trace, tool output, policy document, or identity record copied into one durable artifact. References, version identifiers, controlled digests, masking, and selective disclosure can preserve the relevant evidence while reducing duplicated sensitive context.

Nor is it an audit, compliance, or legal record by itself. It can help reconstruct a decision. It cannot turn technical authorization into legal authority, prove that a policy was correct, certify that a control was effective, or show that the payment was economically wise.

Start with the authority chain

Authentication matters, but the more useful reviewer question is: “What authority did the enforcing system actually evaluate for this payment?”

A practical chain is:

principal or delegator → current agent or actor → mandate/authorization reference → scope and limits → validity and revocation state → policy/version → exact payment proposal → decision

Authentication belongs in that chain, but it is only one layer. Technical standards distinguish authentication from authorization, and delegation can introduce a separate actor acting on behalf of a principal. A reviewer therefore needs to keep identity, authentication, authorization, delegation, policy evaluation, approval, payment processing, and reconciliation distinct.

“Current” also needs a timestamp. A mandate or credential that existed yesterday may be expired, revoked, not yet valid, or out of scope today. The receipt should preserve the state that the enforcing system observed at decision time: the validity window, revocation/activity check, relevant scope, and the source or reference used for that check.

The language should stay technical and specific. “The system recorded the authorization state as active and within the represented scope at 14:03 UTC” is reviewable. “The agent had legal authority” is a different conclusion and needs different evidence.

Bind the decision to the exact payment

A generic spending mandate is not enough if the actual proposal can change.

The decision record should identify the exact payment candidate: request ID, amount and currency or asset, beneficiary or tool/resource, and a canonical reference or digest for the evaluated proposal. Where price, order terms, purpose, instrument, or budget state mattered to the decision, those should be linked too.

This is the difference between approving a category of actions and reconstructing one decision. If the price changes after review, the beneficiary changes, the amount increases, or the submitted request is not the same object that was evaluated, the reviewer needs to see that mismatch rather than inherit an old approval label.

The same logic applies to policy. A decision without the policy version or revision can be impossible to reproduce after the rules change. Current policy tooling can record decision identifiers, inputs, results, timestamps, and policy or bundle revisions. That makes versioned policy provenance a practical precedent for a Decision Receipt.

Keep the decision simple and the evidence specific

For review, Treasury Desk proposes three normalized outcomes:

• ALLOW
• ESCALATE
• DENY

This is a reviewer normalization, not a universal standard. If the source system uses another term—such as REVIEW—the receipt should preserve that source-native outcome alongside the normalized value.

ALLOW means the represented technical checks permitted the exact proposal at decision time. It does not mean the payment was submitted, captured, settled, reconciled, compliant, secure, or economically appropriate.

ESCALATE means the automated evaluation did not finalize the decision and a designated review or exception path is required. It is not approval. If a human later approves the payment, that should be a separate event tied to the same proposal.

DENY means the proposal failed the represented technical policy or authority checks. It is not a fraud finding or a legal prohibition.

Reason codes should be similarly bounded. Useful examples include AUTHORITY_EXPIRED, AUTHORITY_REVOKED, SCOPE_MISMATCH, AMOUNT_OR_BUDGET_EXCEEDED, BENEFICIARY_MISMATCH, TERMS_CHANGED, MANUAL_REVIEW_REQUIRED, and EVIDENCE_INCOMPLETE. If the source system provides its own reason code or evaluation reference, preserve it.

Decision state and payment state are different facts

A common failure is to let one status carry too much meaning.

A reviewer-friendly lifecycle is:

PROPOSED → DECISION → optional APPROVAL → SUBMISSION ATTEMPT → provider/rail states → later settlement/refund/reversal/failure events → RECONCILIATION

This is a reviewer abstraction, not a universal payment-network state machine. Payment providers use their own lifecycle terms, and those terms can change as a payment is confirmed, captured, processed, settled, refused, canceled, refunded, or fails.

The Decision Receipt should therefore keep its original decision-time facts stable and link later payment-state observations. It should not be rewritten so that an earlier ALLOW becomes “paid,” or so that a later refund makes the original policy decision look like a denial.

Reconciliation belongs even later. A provider can report a payment state without finance having matched the event to the expected obligation, identified an exception, or closed the reconciliation. settled and reconciled should never be used as synonyms.

Failure cases the receipt should make visible

The value of the record becomes clearest when the happy path breaks.

For a stale or revoked mandate, the record should show when and where the current-state check was made. For an expired mandate, it should show the validity window and decision timestamp. A scope mismatch should show the requested action or resource against the represented scope. An amount or budget exception should show the proposal amount and the applicable limit reference.

If terms changed, the record should make that visible through proposal or terms binding. An escalation should remain unresolved until a separate review event exists. A human approval should be tied to the exact proposal later submitted. A retry or duplicate attempt should carry its own attempt or idempotency reference where the underlying system supports one.

If the link between the policy decision and the payment attempt is broken, it should stay broken. The system should not infer that two records belong together merely because they involve the same agent or occurred on the same day.

A Decision Receipt also does not prevent replay or duplicate payments. Replay resistance and idempotency are separate protocol or control properties. The receipt can record evidence about those mechanisms; it is not the mechanism itself.

Reviewer Decision Receipt v0.1

Do not over-record by default

Do not copy credentials, bearer tokens, private keys, seed phrases, full payment-instrument data, full prompts, hidden model reasoning, complete agent transcripts, entire policy documents, unrestricted tool outputs, or unrelated personal/customer data into the receipt.

Prefer stable references and the minimum decision-relevant fields. A digest can help with correlation or integrity, but a digest is not proof of authority and is not automatically anonymous.

What this does not prove