A Signed Instruction Is Not Settlement: Finality for Agentic and API Payments
draft-das-payment-execution-finality-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Sangam Das | ||
| Last updated | 2026-09-29 (Latest revision 2026-09-08) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
Before Comparing Meta Muse / Sentinel, Read the Earlier DAS Disclosures: An AI-Assisted Primary-Source Technical Guide — Zenodo
GitHub - Runnable Reference Implementation , Payment Execution Finality for Agentic, API and Automated Payments — |
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-das-payment-execution-finality-01
Network Working Group S. Das
Internet-Draft Independent Inventor
Intended status: Informational 9 September 2026
Expires: 13 March 2027
A Signed Instruction Is Not Settlement: Finality for Agentic and API
Payments
draft-das-payment-execution-finality-01
Abstract
Payment rails already know how to move money. They do not know
whether this generated instruction — this amount, this beneficiary,
this rail, this purpose, from this agent or API worker — is the
instruction that was authorized to move. A signed ISO 20022 message,
an OAuth token on a PSP, a stored mandate, or a pass through 3-D
Secure can all be valid while the act is wrong. The signature
authenticates a channel. It does not bind a Candidate Act at the
settlement sink.
That gap is now an agent gap. A model that can call payout.create, a
RPA job that submits ACH, or a checkout agent that captures a card
will treat tool selection as settlement authority. Fraud used to
steal credentials and replay files. It now steals a seat or injects
a document and asks the authorized worker to pay a new beneficiary at
the old amount, or the old beneficiary at a new amount.
This document specifies a payment-side execution-finality profile.
An instruction remains a Payment Candidate Act. A Protected
Enforcement Domain binds principal, wallet or account, amount,
currency, beneficiary, rail, purpose, policy epoch, and intended
settlement sink, then commits evidence before scoped non-bearer
authority is issued. The sink that would actually post, capture, or
release funds verifies that authority against the live instruction
and consumes it. A signed instruction is not settlement.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Das Expires 13 March 2027 [Page 1]
Internet-Draft Payment Execution Finality September 2026
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 13 March 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. How Payment Abuse Changed . . . . . . . . . . . . . . . . . . 4
2.1. Past: Steal the Instrument . . . . . . . . . . . . . . . 4
2.2. Present: Steal the Session that Can Pay . . . . . . . . . 5
2.3. Future: Compute the Payment, Then Settle It . . . . . . . 5
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
4. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Existing Solutions and What They Do Not Bind . . . . . . . . 6
5.1. ISO 20022, SWIFT, ACH, and Instant Rails . . . . . . . . 6
5.2. OAuth, API Keys, and Open-Banking Consents . . . . . . . 6
5.3. 3-D Secure, SCA, and Step-Up . . . . . . . . . . . . . . 6
5.4. Ledgers, Blockchains, and Smart Contracts . . . . . . . . 7
5.5. Mandates, Standing Orders, and Vendor Master Data . . . . 7
5.6. Human Dual Control . . . . . . . . . . . . . . . . . . . 7
5.7. What This Profile Adds . . . . . . . . . . . . . . . . . 7
6. Difference from Traditional Systems . . . . . . . . . . . . . 7
6.1. What a Traditional System Binds . . . . . . . . . . . . . 8
6.2. Substitutions the Traditional Stack Does Not Stop at the
Sink . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.3. What This Profile Adds . . . . . . . . . . . . . . . . . 9
6.4. Contrast . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Industrial Applicability . . . . . . . . . . . . . . . . . . 12
7.1. PSP and Platform Checkout . . . . . . . . . . . . . . . . 12
7.2. Bank Core, ACH, SEPA, and Instant Credit . . . . . . . . 12
7.3. Corporate AP and Treasury Agents . . . . . . . . . . . . 12
Das Expires 13 March 2027 [Page 2]
Internet-Draft Payment Execution Finality September 2026
7.4. Claims, Insurance, and Benefit Payout . . . . . . . . . . 12
7.5. Payroll and Marketplace Split . . . . . . . . . . . . . . 12
7.6. CBDC, Stored Value, and On-Us Books . . . . . . . . . . . 12
7.7. Agentic Wallets and MCP Payment Tools . . . . . . . . . . 13
7.8. How a Bank Would Pilot in One Quarter . . . . . . . . . . 13
7.9. How a PSP Would Expose It to Platforms . . . . . . . . . 13
8. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 14
10. End-to-End Workflow . . . . . . . . . . . . . . . . . . . . . 14
11. Settlement Pseudocode . . . . . . . . . . . . . . . . . . . . 16
12. JSON Interoperability Profile . . . . . . . . . . . . . . . . 17
12.1. PaymentCandidateAct Schema . . . . . . . . . . . . . . . 17
12.2. Evidence and Authority . . . . . . . . . . . . . . . . . 20
12.3. Sink Verify Allow and Deny . . . . . . . . . . . . . . . 22
12.4. Complete Allow Transaction . . . . . . . . . . . . . . . 23
13. Load-Bearing Bindings . . . . . . . . . . . . . . . . . . . . 24
14. Practical Feasibility: Latency and Legacy . . . . . . . . . . 24
14.1. Where the Microseconds Go . . . . . . . . . . . . . . . 25
14.2. Hot-Path Envelope . . . . . . . . . . . . . . . . . . . 25
14.3. Coexistence with ISO 20022 and Clearing Files . . . . . 25
14.4. Coexistence with Card Acquirers . . . . . . . . . . . . 26
14.5. Coexistence with Core Banking . . . . . . . . . . . . . 26
14.6. Coexistence with Agent Runtimes . . . . . . . . . . . . 26
14.7. Failure Modes that Legacy Staff Will Recognize . . . . . 26
14.8. Informative Mapping onto ISO 20022 Credit Transfer . . . 26
14.9. Informative Mapping onto Card Capture . . . . . . . . . 27
14.10. What This Profile Does Not Require . . . . . . . . . . . 27
15. Cross-Border, FX, and Split Legs . . . . . . . . . . . . . . 27
16. Dual Control and Threshold Authority . . . . . . . . . . . . 28
17. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 28
17.1. Trust Boundary and Adversary Capabilities . . . . . . . 28
17.2. Out-of-Scope Threats . . . . . . . . . . . . . . . . . . 30
17.3. Threat-to-Mitigation Mapping . . . . . . . . . . . . . . 30
18. Payment Threat Catalog . . . . . . . . . . . . . . . . . . . 32
19. Additional Worked Denials . . . . . . . . . . . . . . . . . . 33
20. Regulatory and Operational Notes . . . . . . . . . . . . . . 34
21. Failure Codes and Denial Behavior . . . . . . . . . . . . . . 34
22. Combined Agent Tool Call and Payment Act . . . . . . . . . . 35
23. Security Considerations . . . . . . . . . . . . . . . . . . . 36
24. Privacy Considerations . . . . . . . . . . . . . . . . . . . 36
25. Relevance to IETF Working Groups . . . . . . . . . . . . . . 36
26. Implementation Checklist . . . . . . . . . . . . . . . . . . 37
27. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
28. Intellectual Property and Licensing . . . . . . . . . . . . . 38
29. Reference Implementation . . . . . . . . . . . . . . . . . . 39
30. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 41
31. Normative References . . . . . . . . . . . . . . . . . . . . 41
32. Informative References . . . . . . . . . . . . . . . . . . . 41
Das Expires 13 March 2027 [Page 3]
Internet-Draft Payment Execution Finality September 2026
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction
The payment path, whether a human treasury screen, a batch file, or
an agent tool call, is now:
policy / model / ERP / agent
-> payment instruction {amount, payee, rail}
-> signed or tokenized submit
-> PSP / core / card / CBDC engine
-> funds move
This document controls the last arrow. The computer may compute an
instruction. The rail may authenticate the sender. Neither fact is
authority for this amount to leave this account toward this
beneficiary on this rail in this epoch. Section 4 enumerates the
failure classes this profile treats as first-class; Section 5 surveys
what messaging standards, tokens, step-up authentication, ledgers,
mandates, and dual control already bind and what each leaves open;
Section 6 states the difference from those traditional channel and
class controls and what this profile adds at the settlement sink.
The profile uses the two-boundary chain in [I-D.das-6g-finality] and
the tool-dispatch objects in [I-D.das-agentic]. It specifies only
payment predicates those drafts leave as an enum: amount and currency
binding, beneficiary and rail binding, mandate and purpose binding,
idempotency as consume-once authority, and coexistence with ISO
20022, ACH, card capture, and instant-payment APIs.
2. How Payment Abuse Changed
2.1. Past: Steal the Instrument
Historical payment crime stole the thing that was already money: a
card number, a cheque, a batch file, a SWIFT token on a compromised
treasury PC. Defense was instrument-centric. Reissue the card.
Rotate the MAC. Watch for a file that did not match yesterday's
template. The valuable object was a credential or a pre-built
instruction the business had already approved as a class.
Das Expires 13 March 2027 [Page 4]
Internet-Draft Payment Execution Finality September 2026
2.2. Present: Steal the Session that Can Pay
Present abuse often leaves the instrument in place. The attacker
takes an ERP session, a PSP dashboard cookie, an agent seat with
payout.create enabled, or a poisoned invoice PDF that the AP bot is
allowed to read. Strong customer authentication and OAuth are up.
The worker is allowed to pay. The instruction it emits is not the
one the mandate described.
Business email compromise already showed the pattern without models:
a lawful payer, a new beneficiary string, a valid signature on the
channel. Agentic checkout and AP agents industrialize that pattern.
Every tool-enabled seat is a treasury clerk that never sleeps and
that will treat retrieved text as an instruction.
2.3. Future: Compute the Payment, Then Settle It
The coming incident does not need the attacker to format ISO 20022.
The model formats it. A reconstructed "we owe this vendor" join from
mail plus ERP plus a prompt-injected statement becomes a Candidate
Act that looks like ordinary automation. If the settlement engine
accepts any authenticated submit from that worker, reconstruction
becomes cash.
This profile exists so that even a correctly signed, schema-valid,
token-bearing instruction remains non-effective until the sink checks
the act digest against current authority. Settlement is not a
synonym for "the API returned 200."
3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Failure to establish current payment-finality authority MUST NOT be
converted into permission to post, capture, release, or otherwise
settle funds.
4. Problem Space
A payment instruction is a Candidate Act with a consequence class
that is almost never informational. Once the rail posts, reversal is
a business process, not a protocol rollback. The failures this
profile treats as first-class are:
Das Expires 13 March 2027 [Page 5]
Internet-Draft Payment Execution Finality September 2026
* Amount substitution after approval of 50.00 as 5,000.00 on the
same beneficiary and rail.
* Beneficiary substitution after approval of a named payee.
* Rail substitution (internal book-transfer authority reused on an
external instant rail).
* Replay of a consumed instruction under a new idempotency key or on
a second PSP.
* Mandate or purpose drift (invoice-pay authority used for payroll
or cross-border).
* Agent or worker substitution (approved bot A, executing bot B).
* Destination-account reuse after revocation or beneficiary-risk
list update.
In each case some upstream control can be green: the OAuth token is
live, the ISO message verifies, the mandate exists, the agent is in
the allowlist. The missing question is the sink question: may this
exact instruction settle now.
5. Existing Solutions and What They Do Not Bind
5.1. ISO 20022, SWIFT, ACH, and Instant Rails
Messaging standards authenticate and structure instructions. They
bind fields inside a message. They do not, by themselves, consume
single-use authority at the posting engine, and they do not stop a
second valid message that differs in one load-bearing field after a
human or model "approved payments."
5.2. OAuth, API Keys, and Open-Banking Consents
Tokens establish that a client may call a payment API. Consent often
names an account and a period. Possession of the token is bearer-
like with respect to every instruction that token can form. Act
digest, beneficiary bind, and consume-once are application additions,
not properties of the token.
5.3. 3-D Secure, SCA, and Step-Up
Payer authentication answers "is a human present for this merchant
session." It does not hash the agent-generated split of amount and
payee after the session, and it does not sit in a payout API that
never sees a cardholder.
Das Expires 13 March 2027 [Page 6]
Internet-Draft Payment Execution Finality September 2026
5.4. Ledgers, Blockchains, and Smart Contracts
A chain can make a transfer final among participants. It does not
decide whether the off-chain agent was authorized to construct that
transfer. Posting a stolen-but-valid signed payload is still
settlement. External anchoring MUST NOT retroactively authorize an
act that was invalid at effectuation time.
5.5. Mandates, Standing Orders, and Vendor Master Data
A mandate is a class approval. Vendor master data is a directory.
Neither is an act-specific, amount-bound, nonce-bound capability at
the sink. An agent that is allowed to "pay approved vendors" can
still pick the wrong vendor row or the wrong invoice total.
5.6. Human Dual Control
Maker-checker is the correct industrial instinct. It is slow, and
agents exist to skip the queue. This profile does not delete dual
control. It makes the checker a predicate that can be a human share,
a policy share, or a threshold of both, and it still requires the
sink consume the resulting authority.
5.7. What This Profile Adds
* the instruction remains a Payment Candidate Act after the model,
ERP, or file emitter produces it;
* amount, currency, beneficiary, rail, and purpose are in the
digest;
* authority is non-bearer, sink-bound, epoch-bound, and consumed;
* idempotency is consume-once of that digest, not a client-supplied
string the attacker can refresh;
* legacy rails remain the transport; the sink check is the gate;
* hot-path envelopes exist so instant payments are not forced
through a remote ledger round trip.
6. Difference from Traditional Systems
Traditional payment systems authenticate who may submit and that the
message is well-formed. This profile binds whether this exact
instruction may change a balance now. That is the difference.
Das Expires 13 March 2027 [Page 7]
Internet-Draft Payment Execution Finality September 2026
6.1. What a Traditional System Binds
A normal path is:
policy / ERP / agent
-> instruction {amount, payee, rail}
-> signed or tokenized submit
-> PSP / core / card / CBDC
-> funds move
Controls on that path answer a channel or class question. They do
not answer the sink question.
* ISO 20022, SWIFT, ACH, and instant messages bind structure and
sender authentication. They do not consume single-use authority
at the posting engine for this amount, beneficiary, and rail.
* OAuth, API keys, and open-banking consents bind that a client may
call a payment API for an account and period. Possession of the
token is bearer-like for every instruction that token can form.
* 3-D Secure and SCA bind that a human was present for a merchant
session. They do not hash an agent-built split of amount and
payee after the session, and they do not sit on a payout API that
never sees a cardholder.
* A mandate, standing order, or vendor master record is a class
approval or a directory. It is not an act-specific, amount-bound,
nonce-bound capability at the sink. An agent allowed to "pay
approved vendors" can still pick the wrong vendor row or the wrong
invoice total.
* A client idempotency key binds that a string was seen. An
attacker can keep the key and change the body, or mint a new key
for the same act on a second PSP.
* A ledger or chain can make a transfer final among participants.
It does not decide whether the off-chain agent was authorized to
construct that transfer. Posting a stolen-but-valid signed
payload is still settlement.
* Maker-checker binds two humans to a screen. An API can still post
without those shares. Agents exist to skip the queue.
Das Expires 13 March 2027 [Page 8]
Internet-Draft Payment Execution Finality September 2026
The traditional failure mode is: channel valid, act wrong. Business
email compromise already showed the pattern without models: a lawful
payer, a new beneficiary string, a valid signature on the channel.
Agentic checkout and AP workers industrialize that pattern. Fraud
used to steal the instrument. It now steals the session that can
pay.
6.2. Substitutions the Traditional Stack Does Not Stop at the Sink
* Amount substitution after approval of 50.00 as 5,000.00 on the
same beneficiary and rail.
* Beneficiary substitution after approval of a named payee.
* Rail substitution (internal book-transfer authority reused on an
external instant rail).
* Replay of a consumed instruction under a new idempotency key or on
a second PSP.
* Mandate or purpose drift (invoice-pay authority used for payroll
or cross-border).
* Agent or worker substitution (approved bot A, executing bot B).
* Destination-account reuse after revocation or beneficiary-risk
list update.
In each case some upstream control can be green: the OAuth token is
live, the ISO message verifies, the mandate exists, the agent is in
the allowlist. The missing question is whether this exact
instruction may settle now.
6.3. What This Profile Adds
The profile inserts a hold state and a second check immediately
before balance change.
Das Expires 13 March 2027 [Page 9]
Internet-Draft Payment Execution Finality September 2026
instruction emitted
|
v
PAYMENT CANDIDATE ACT (NON_EFFECTIVE)
|
v
Protected Enforcement Domain
binds payer, account, amount, CCY,
beneficiary, rail, purpose,
mandate/SCA inputs, epochs, sink
|
v
evidence committed + scoped authority
|
v
SETTLEMENT SINK
PASS -> post once, consume authority
FAIL -> no balance change
The following properties are not protocol properties of ISO 20022,
OAuth, 3-D Secure, or mandates. They are required by this profile:
1. The generated instruction is a Payment Candidate Act. It is not
settlement. Status starts NON_EFFECTIVE.
2. An instruction digest covers canonical amount, currency,
beneficiary, rail, account references, purpose, and other load-
bearing fields. Changing any of them MUST change the digest.
Authority for 150.00 EUR / vendor-441 / SEPA_INSTANT / digest D1
MUST NOT authorize 1,500.00, USD, vendor-442, ACH, or digest D2.
3. The Protected Enforcement Domain validates predicates, commits
Protected Validation Evidence, then issues scoped Payment
Finality Authority. A PED that returns ALLOW=true without a
stored evidence_id has issued a boolean, not this profile.
Authority is non-bearer, sink-bound, epoch-bound, and single-use.
4. The Settlement Sink is the component that would actually post,
capture, or release. It verifies the live instruction against
that authority and consumes the authority atomically with the
post. post_to_rail() is unreachable when any check fails. A 200
from an inner HTTP client after a failed check is non-conforming.
Timeout MUST NOT post.
5. Idempotency is consume-once of the instruction digest and
authority_id, not a client-supplied string the attacker can
refresh.
Das Expires 13 March 2027 [Page 10]
Internet-Draft Payment Execution Finality September 2026
6. A mandate remains a class-level input to PED validation. It MUST
NOT by itself be settlement authority for a particular act.
7. A hot-path envelope MAY cache predicates (payer, rail, currency,
ceiling, beneficiary set, epochs, sink). It MUST still compare
the digest and sink identifier and MUST still consume. Cold path
MUST NOT be skipped by timeout.
8. When the instruction is born as a model tool call, both an agent
or tool-dispatch check and a payment-sink check are required. If
only the dispatcher checks, a handler bug can still post. If
only the posting sink checks, a raw HTTP call to the PSP can
still fire.
9. Legacy rails remain the transport. ISO 20022, ACH, cards, and
instant APIs are not replaced. The admission gate sits
immediately before the component that marks the instruction
released to clearing or capture.
6.4. Contrast
Traditional controls bind the channel and the class of payer. This
profile binds the candidate act at the settlement sink: amount,
currency, beneficiary, rail, purpose, epoch, and consume-once
authority.
* Traditional: a signature, token, mandate, or 3-D Secure result
means the worker may pay. This profile: those results are inputs.
Only consumed, sink-bound, digest-matched authority means this act
may settle.
* Traditional: settlement is treated as equivalent to "the API
returned 200." This profile: settlement is atomic consume plus
post at the sink.
* Traditional: defense is instrument-centric and channel-centric.
This profile: defense is act-centric at effectuation time.
* Traditional: replay and field substitution are application
defects. This profile: they are protocol denies
(EF_INSTRUCTION_SUBSTITUTION, EF_SINK_MISMATCH,
EF_AUTHORITY_ALREADY_USED, and related codes).
Das Expires 13 March 2027 [Page 11]
Internet-Draft Payment Execution Finality September 2026
This document does not specify a new rail, a blockchain on the
posting path, or a requirement that the model detect fraud. It does
not claim to replace PSD2, SCA, PCI DSS, AML, or sanctions screening.
Those systems produce inputs. A clean screen of vendor-441 does not
authorize a post to attacker-992. A signed instruction is not
settlement.
7. Industrial Applicability
7.1. PSP and Platform Checkout
A commerce agent or checkout API already holds a capture token. The
sink is the capture or refund call. Authority issued for capture
40.00 at merchant M MUST fail for 4,000.00 or merchant M2.
7.2. Bank Core, ACH, SEPA, and Instant Credit
The sink is the posting service that would debit the payer and emit
the clearing message. ISO 20022 remains the payload. The Finality
Sink verifies the Payment Candidate Act before the message is
considered released to clearing.
7.3. Corporate AP and Treasury Agents
ERP and TMS tools already batch pay. An agent that reads invoices is
the present-theft seat. The RAO-like purpose bind is invoice-pay.
Payroll and tax rails are different consequence scopes.
7.4. Claims, Insurance, and Benefit Payout
A claims agent proposing a payee from a repair invoice is a
beneficiary-substitution surface. Settlement authority MUST bind
payee account digest, not only claim-id.
7.5. Payroll and Marketplace Split
Many small legs share one worker token. Each leg is its own
Candidate Act. A digest for worker A / 1200.00 MUST not authorize
worker B / 1200.00.
7.6. CBDC, Stored Value, and On-Us Books
Whether the engine is a CBDC participant, an e-money ledger, or an
internal book, the sink is the component that would change balances.
This document does not specify a CBDC protocol. It specifies that
balance change is effectuation.
Das Expires 13 March 2027 [Page 12]
Internet-Draft Payment Execution Finality September 2026
7.7. Agentic Wallets and MCP Payment Tools
payout.create on an MCP server is a tool call under [I-D.das-agentic]
and a payment act under this profile. Both checks are required when
the tool would move value. Discovery of the server is not mandate
authority.
7.8. How a Bank Would Pilot in One Quarter
Pick one outbound API used by a new AP agent or by a single PSP
payout route. Deploy the consume table next to the existing
idempotency store. Issue authority only for that route's currency
and ceiling. Leave the green-screen path on maker-checker. Measure
posts without authority_id, digest mismatches, replay attempts, and
added latency at p50 and p99. Expand rail by rail. This is a pilot,
not a core replacement.
7.9. How a PSP Would Expose It to Platforms
Offer an optional header carrying the authority object and the
instruction digest the platform computed. If the header is absent,
today's token behavior remains for legacy platforms. If the header
is present, the PSP becomes a cooperating sink and rejects mismatch.
Platforms that run agents SHOULD move to header-present. That is how
the profile meets the industry without a flag day.
8. Terminology
Payment Candidate Act
A generated or selected instruction that would debit, credit,
capture, refund, release, or otherwise change a balance, but has
not been permitted to do so.
Settlement Sink
The component that would actually post the instruction to a
ledger, clearing file, card acquirer, CBDC engine, or stored-value
book. If that component can be skipped, it is not the sink.
Instruction digest
A hash over the canonical amount, currency, beneficiary, rail,
account references, purpose, and other load-bearing fields.
Changing any of them MUST change the digest.
Mandate
A class-level approval (vendor, merchant, account, ceiling). A
mandate MAY be an input to PED validation. It MUST NOT by itself
be settlement authority for a particular act.
Das Expires 13 March 2027 [Page 13]
Internet-Draft Payment Execution Finality September 2026
9. Architecture
ERP / agent / checkout emits instruction
|
v
PAYMENT CANDIDATE ACT
|
v
Non-Effective State
|
v
Protected Enforcement Domain
payer, account, amount, CCY
beneficiary, rail, purpose
mandate / SCA inputs
policy and revocation epochs
intended settlement sink
|
v
evidence + scoped authority
|
v
SETTLEMENT SINK
|
+-- PASS -> post once, consume authority
|
`-- FAIL -> no balance change
Figure 1: Settlement-time finality
10. End-to-End Workflow
1. Instruction constructed by agent, API, file, or human UI.
Status NON_EFFECTIVE.
2. Canonicalize load-bearing fields. Compute instruction digest.
3. Build PaymentCandidateAct including payer, accounts, amount,
currency, beneficiary, rail, purpose, freshness, sink, epochs.
4. PED validates predicates, including mandate envelope and risk
lists where required.
5. On fail: deny; lock or quarantine the affected nonce, quota, or
protected state to prevent replay, rollback, stale retry,
substitution, or cross-sink reuse of the denied Candidate Act;
commit denial evidence (a denial LAVR or equivalent protected
enforcement record) as evidence of non-completion. Do not post.
Das Expires 13 March 2027 [Page 14]
Internet-Draft Payment Execution Finality September 2026
6. On pass: update and consume the relevant protected state (nonce,
quota, budget, session, revocation, or monotonic counter) so
that a concurrent or later validation pass cannot reuse the same
protected state before evidence is committed.
7. Commit Protected Validation Evidence, referencing the protected-
state transition performed in the previous step.
8. Issue scoped Payment Finality Authority bound to the digest,
sink, epochs, and single-use flag.
9. Transport the instruction on the legacy rail (ISO, ACH, card,
HTTP) together with the authority reference or an attached
object.
10. Settlement Sink builds or reconstructs a sink-side descriptor of
the live instruction and local effectuation boundary.
11. Settlement Sink verifies the scoped authority against that sink-
side descriptor, the digest, sink, boundary, nonce, policy
epoch, evidence reference, and scope, immediately before post.
12. Atomic consume + post, or fail-closed deny with no post if sink
verification fails.
13. Record sink-side settlement evidence. Do not treat rail ACK as
a substitute for consume.
Stage notes that implementations get wrong:
Canonicalization MUST include amount scale. 150, 150.0, and 150.00
are the same act only if the canonical form says so. Implementations
SHOULD normalize to a fixed scale per currency (two for EUR, zero for
JPY unless policy says otherwise) before hashing.
expires_at on the Candidate Act is not the rail cut-off time. It is
the authority TTL. A SEPA instant that settles in two seconds still
uses a short TTL so a queued instruction cannot sit overnight and
post after a risk-list change.
Evidence commitment is constitutive. A PED that returns ALLOW=true
without a stored evidence_id has issued a boolean, not this profile.
The sink MUST be able to resolve the evidence or MUST treat the
authority as invalid.
Das Expires 13 March 2027 [Page 15]
Internet-Draft Payment Execution Finality September 2026
Consume and post SHOULD be one database transaction or an equivalent
compare-and-swap. Consume-then- crash-then-repost without a durable
consume bit is a replay window. Post-then-crash-then-fail-to-
consume is a double-post window on retry. The safe pattern is: write
consumed+pending, post, write posted; retries read the row.
11. Settlement Pseudocode
function ON_PAYMENT_INSTRUCTION(ins, ctx):
act = PaymentCandidateAct{
candidate_act_id: fresh_id(),
act_type: map_rail(ins.rail),
payer: ctx.payer,
amount: ins.amount,
currency: ins.currency,
beneficiary: canonical_payee(ins),
rail: ins.rail,
purpose: ins.purpose,
instruction_digest: HASH(canonicalize(ins)),
policy_state: current_epochs(),
freshness: {nonce: fresh_nonce()},
finality_sink: ctx.settlement_sink,
expires_at: now() + short_ttl
}
HOLD_NON_EFFECTIVE(act)
return PED_VALIDATE(act, ins)
function PED_VALIDATE(act, ins):
if malformed(act) or amount <= 0:
return DENY(MALFORMED_ACT)
if not fresh(act.freshness.nonce):
return DENY(REPLAY_OR_STALE)
if act.policy_state != current_epochs():
return DENY(EPOCH_MISMATCH)
if not mandate_covers(act):
return DENY(MANDATE_MISS)
if beneficiary_blocked(act.beneficiary):
return DENY(PAYEE_BLOCKED)
if act.amount > hot_envelope_ceiling(act) and
not cold_path_approved(act):
return ESCALATE_OR_DENY(AMOUNT_ENVELOPE)
evidence = COMMIT_PROTECTED_EVIDENCE(act)
authority = ISSUE_SCOPED_AUTHORITY(act, evidence)
return ALLOW(authority)
function SETTLEMENT_SINK_POST(act, authority, live):
live_digest = HASH(canonicalize(live))
if authority missing or integrity_fail(authority):
Das Expires 13 March 2027 [Page 16]
Internet-Draft Payment Execution Finality September 2026
return DENY(NO_OR_INVALID_AUTHORITY)
if live_digest != act.instruction_digest:
return DENY(INSTRUCTION_SUBSTITUTION)
if authority.sink_id != THIS_SINK:
return DENY(SINK_MISMATCH)
if live.amount != authority.amount or
live.currency != authority.currency or
canonical_payee(live) != authority.beneficiary:
return DENY(FIELD_MISMATCH)
if expired(authority) or consumed(authority):
return DENY(STALE_OR_USED)
ATOMICALLY:
consume(authority)
advance_replay_state(act.freshness.nonce)
result = post_to_rail(live)
record_sink_evidence(act, authority, result)
return result
post_to_rail() is unreachable when any check fails. A 200 from an
inner HTTP client after a failed check is non-conforming.
12. JSON Interoperability Profile
Objects are UTF-8 JSON. additionalProperties MUST be treated as
reject for load-bearing objects. Amounts SHOULD be decimal strings
to avoid binary float drift. Canonicalization for the digest SHOULD
be JCS or an implementation-defined stable form declared in the
digest object.
12.1. PaymentCandidateAct Schema
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "urn:ietf:params:json-schema:payment-finality:candidate-act:1",
"title": "PaymentCandidateAct",
"type": "object",
"additionalProperties": false,
"required": [
"version", "object_type", "candidate_act_id", "act_type",
"created_at", "expires_at", "payer", "amount", "currency",
"beneficiary", "rail", "purpose", "instruction_digest",
"policy_state", "freshness", "finality_sink"
],
"properties": {
"version": { "type": "string", "const": "1.0" },
"object_type": {
"type": "string",
"const": "payment_candidate_act"
Das Expires 13 March 2027 [Page 17]
Internet-Draft Payment Execution Finality September 2026
},
"candidate_act_id": {
"type": "string",
"minLength": 16,
"maxLength": 128
},
"act_type": {
"type": "string",
"enum": [
"CREDIT_TRANSFER", "DIRECT_DEBIT", "CARD_CAPTURE",
"CARD_REFUND", "INSTANT_CREDIT", "BOOK_TRANSFER",
"STORED_VALUE", "CBDC_TRANSFER", "PAYOUT",
"FX_PAYOUT", "OTHER"
]
},
"created_at": { "type": "string", "format": "date-time" },
"expires_at": { "type": "string", "format": "date-time" },
"payer": {
"type": "object",
"required": ["payer_id", "account_ref"],
"properties": {
"payer_id": { "type": "string" },
"payer_type": {
"type": "string",
"enum": ["person", "merchant", "enterprise", "agent", "service"]
},
"account_ref": { "type": "string" },
"agent_id": { "type": "string" },
"workload_id": { "type": "string" }
}
},
"amount": {
"type": "string",
"pattern": "^[0-9]+(\\.[0-9]{1,18})?$"
},
"currency": {
"type": "string",
"minLength": 3,
"maxLength": 8
},
"beneficiary": {
"type": "object",
"required": ["beneficiary_id"],
"properties": {
"beneficiary_id": { "type": "string" },
"account_ref": { "type": "string" },
"account_digest": { "type": "string" },
"name_digest": { "type": "string" },
Das Expires 13 March 2027 [Page 18]
Internet-Draft Payment Execution Finality September 2026
"jurisdiction": { "type": "string" }
}
},
"rail": {
"type": "object",
"required": ["rail_id"],
"properties": {
"rail_id": {
"type": "string",
"enum": [
"ISO20022", "ACH", "SEPA", "SEPA_INSTANT",
"FEDNOW", "CARD", "SWIFT", "ON_US",
"CBDC", "STORED_VALUE", "OTHER"
]
},
"scheme": { "type": "string" },
"clearing_system": { "type": "string" }
}
},
"purpose": {
"type": "object",
"required": ["purpose_id"],
"properties": {
"purpose_id": { "type": "string" },
"declared_purpose": { "type": "string" },
"invoice_ref": { "type": "string" },
"mandate_id": { "type": "string" },
"end_to_end_id": { "type": "string" }
}
},
"instruction_digest": {
"type": "object",
"required": ["algorithm", "value", "canonicalization"],
"properties": {
"algorithm": {
"type": "string",
"enum": ["SHA-256", "SHA-384", "SHA-512"]
},
"value": { "type": "string" },
"canonicalization": {
"type": "string",
"enum": ["JCS", "implementation-defined"]
}
}
},
"policy_state": {
"type": "object",
"required": ["policy_epoch", "revocation_epoch"],
Das Expires 13 March 2027 [Page 19]
Internet-Draft Payment Execution Finality September 2026
"properties": {
"policy_epoch": { "type": "integer", "minimum": 0 },
"revocation_epoch": { "type": "integer", "minimum": 0 },
"risk_list_epoch": { "type": "integer", "minimum": 0 }
}
},
"freshness": {
"type": "object",
"required": ["nonce"],
"properties": {
"nonce": { "type": "string", "minLength": 16 },
"sequence": { "type": "integer", "minimum": 0 },
"idempotency_key": { "type": "string" }
}
},
"finality_sink": {
"type": "object",
"required": ["sink_id", "sink_type"],
"properties": {
"sink_id": { "type": "string" },
"sink_type": {
"type": "string",
"enum": [
"CORE_POST", "PSP_CAPTURE", "ACH_RELEASE",
"INSTANT_RELEASE", "CARD_ACQUIRER",
"CBDC_ENGINE", "LEDGER_POST", "OTHER"
]
}
}
}
}
}
12.2. Evidence and Authority
Das Expires 13 March 2027 [Page 20]
Internet-Draft Payment Execution Finality September 2026
{
"version": "1.0",
"object_type": "protected_validation_evidence",
"evidence_id": "pve-pay-01",
"candidate_act_id": "act-pay-7f39",
"decision": "ALLOW",
"validated_predicates": {
"mandate_covers": true,
"amount_in_envelope": true,
"beneficiary_not_blocked": true,
"rail_permitted": true,
"purpose_valid": true,
"epoch_valid": true,
"freshness_valid": true,
"sink_binding_valid": true
},
"issued_at": "2026-08-27T02:15:01Z",
"protector": {
"type": "HSM_SIGNATURE",
"key_id": "ped-pay-3",
"signature": "base64url-signature"
}
}
Das Expires 13 March 2027 [Page 21]
Internet-Draft Payment Execution Finality September 2026
{
"version": "1.0",
"object_type": "payment_finality_authority",
"authority_id": "pfa-88c0",
"candidate_act_id": "act-pay-7f39",
"evidence_id": "pve-pay-01",
"scope": {
"act_type": "INSTANT_CREDIT",
"amount": "150.00",
"currency": "EUR",
"beneficiary_id": "vendor-441",
"rail_id": "SEPA_INSTANT"
},
"binding": {
"instruction_digest": {
"algorithm": "SHA-256",
"value": "base64url-ins-digest"
},
"nonce": "A81D4F42B779CC21",
"policy_epoch": 12,
"revocation_epoch": 4,
"finality_sink_id": "core-post-eu-1"
},
"lifetime": {
"issued_at": "2026-08-27T02:15:01Z",
"expires_at": "2026-08-27T02:15:11Z",
"single_use": true
}
}
12.3. Sink Verify Allow and Deny
Das Expires 13 March 2027 [Page 22]
Internet-Draft Payment Execution Finality September 2026
{
"operation": "SettlementSinkVerify",
"request_id": "stl-req-09",
"decision": "ALLOW",
"verification": {
"authority_signature": "VALID",
"instruction_digest": "MATCH",
"amount": "MATCH",
"beneficiary": "MATCH",
"rail": "MATCH",
"nonce": "FRESH",
"epochs": "CURRENT",
"consumption_state": "UNUSED",
"sink_binding": "MATCH"
},
"consumption": {
"authority_id": "pfa-88c0",
"status": "CONSUMED"
},
"effectuation": {
"permitted": true,
"settlement_ref": "e2e-441-19"
}
}
{
"operation": "SettlementSinkVerify",
"request_id": "stl-req-10",
"decision": "DENY",
"error": {
"code": "EF_INSTRUCTION_SUBSTITUTION",
"message": "Live amount does not match authorized digest.",
"retryable": false
},
"effectuation": { "permitted": false }
}
12.4. Complete Allow Transaction
Das Expires 13 March 2027 [Page 23]
Internet-Draft Payment Execution Finality September 2026
{
"step_1_instruction": {
"act_type": "INSTANT_CREDIT",
"amount": "150.00",
"currency": "EUR",
"beneficiary_id": "vendor-441",
"rail_id": "SEPA_INSTANT",
"purpose_id": "invoice-pay",
"status": "NON_EFFECTIVE"
},
"step_2_digest": {
"algorithm": "SHA-256",
"value": "base64url-ins-digest"
},
"step_3_authority": {
"authority_id": "pfa-88c0",
"single_use": true,
"expires_at": "2026-08-27T02:15:11Z"
},
"step_4_sink": {
"decision": "ALLOW",
"authority_consumed": true
},
"step_5_effect": "SEPA instant posted once for digest-bound 150.00 EUR"
}
13. Load-Bearing Bindings
Authority for amount 150.00 / EUR / vendor-441 / SEPA_INSTANT /
digest D1 MUST NOT authorize 1,500.00, USD, vendor-442, ACH, or
digest D2. DISPLAY-equivalent mistakes in this profile are amount
substitution, beneficiary substitution, and rail substitution.
Book-transfer authority MUST NOT automatically authorize an external
instant rail. Refund authority MUST NOT automatically authorize a
new capture. Authority created under revocation epoch N MUST fail at
N+1, including after a beneficiary-risk-list update.
14. Practical Feasibility: Latency and Legacy
A profile that cannot sit on a 200 ms instant-payment path, or that
demands a greenfield ledger, will not be deployed. This section
states how the checks fit existing engines.
Das Expires 13 March 2027 [Page 24]
Internet-Draft Payment Execution Finality September 2026
14.1. Where the Microseconds Go
The load-bearing work at the sink is: parse live fields, hash the
canonical instruction, verify a signature or MAC on the authority,
compare digest and sink id, test consume-once, post. That is the
same order of cost as an existing idempotency-key table plus an HSM
MAC verify. Representative targets, not protocol constants:
* hot path, local policy and local consume table: about 1-10 ms
added to an already-authorized envelope;
* card or PSP capture on the same host as the enforcer: similar;
* cold path with fresh beneficiary risk, new country, or amount
above envelope: tens to hundreds of ms plus any human share;
* external transparency log or chain anchor: asynchronous after
post, never on the enable path.
The architectural split is the same as in [I-D.das-6g-finality]: hot
path still verifies at the sink; cold path must not be skipped by
timeout.
14.2. Hot-Path Envelope
A cold evaluation MAY establish a bounded envelope: payer account A,
rail SEPA_INSTANT, currency EUR, max amount 500.00, beneficiary set
S, purpose invoice-pay, epochs (P,R), sink core-post-eu-1, valid-
until T. Later instructions inside that envelope MAY use local
validation. Any change of beneficiary, rail, currency, ceiling, or
epoch MUST escalate. "Hot" means cached predicates. It does not
mean skip consume or skip digest compare.
14.3. Coexistence with ISO 20022 and Clearing Files
The Finality Sink SHOULD sit immediately before the component that
marks an instruction released to clearing. The ISO message can carry
an end-to-end id that equals or hashes to candidate_act_id. The
authority object MAY travel in an accompanying API header, a private
supplementary data block, or a side channel keyed by that id.
Clearing houses that cannot parse the object still receive only
messages the sink has already admitted.
Batch ACH or payroll files are N Candidate Acts, not one. A file-
level signature is channel authentication. Each row still needs a
digest and consume, or a tightly bound envelope that lists row
digests.
Das Expires 13 March 2027 [Page 25]
Internet-Draft Payment Execution Finality September 2026
14.4. Coexistence with Card Acquirers
Capture and refund APIs already have idempotency keys. This profile
treats that key as insufficient if the body can change under the same
key, and as insufficient if a second acquirer accepts the same
logical act. The sink is the acquirer-facing submitter in the
merchant or platform, or the acquirer itself where the acquirer
agrees to verify the authority object.
14.5. Coexistence with Core Banking
Cores already implement posting, holds, and double-entry. The
feasible placement is a pre-post adapter: no new general ledger, no
new rail. The consume table can be a compare-and-swap row next to
the existing idempotency store. If the core cannot host the adapter,
the adapter MUST be in-line so that bypassing it makes posting
impossible.
14.6. Coexistence with Agent Runtimes
For MCP and function-calling agents the payment tool handler MUST
call SETTLEMENT_SINK_POST before any PSP SDK. A local Python or
TypeScript enforcer that only checks allowlists is not this profile
unless it consumes digest-bound authority. Combining this document
with [I-D.das-agentic] means: build AgentCandidateAct for the tool
call and PaymentCandidateAct for the value move, or one object that
satisfies both required sets.
14.7. Failure Modes that Legacy Staff Will Recognize
Timeout toward the PED is hold-or-deny, the same instinct as "do not
auto-approve an SCA fail." Duplicate file submission is consume-
once, the same instinct as ACH duplicate detection, but keyed by
digest not by filename. Beneficiary change after checker approval is
field mismatch, the same instinct as maker-checker, automated.
A pilot that only wraps the payout API used by the new agent, and
leaves the green-screen treasury path on dual control, is a
conforming incremental deployment. Alternate-path closure says the
green-screen path MUST eventually grow the same consume semantics if
it can emit the same rail message. It does not require a big-bang
cutover on day one.
14.8. Informative Mapping onto ISO 20022 Credit Transfer
The following mapping is informative and does not modify ISO 20022.
It exists so a payments engineer can see that this profile is an
admission gate, not a competing message.
Das Expires 13 March 2027 [Page 26]
Internet-Draft Payment Execution Finality September 2026
* candidate_act_id — may populate or hash into EndToEndId /
InstructionId.
* amount + currency — InstdAmt / EqvtAmt and Ccy.
* beneficiary account_ref or account_digest — CdtrAcct.Id (digest
preferred in authority objects that leave the host).
* purpose.invoice_ref — RmtInf or Purp.
* rail_id SEPA / SWIFT / FedNow — clearing channel already selected
by the core.
* authority_id — private supplementary data or an API header on the
submit that precedes clearing release.
If InstdAmt changes after authority issuance, the live digest MUST
fail. If only ReltdRmtInf narrative changes and policy treats
remittance as non-load-bearing, implementations MAY exclude it from
the digest. That exclusion MUST be explicit. Silent exclusion of
creditor account is non-conforming.
14.9. Informative Mapping onto Card Capture
amount and currency map to capture amount. beneficiary_id maps to
merchant or sub-merchant. rail CARD maps to the acquirer route.
purpose may carry order_id. A refund is a different act_type. Using
a capture authority to refund, or a 40.00 capture authority to
capture 400.00, MUST deny. 3DS or SCA results MAY appear as PED
inputs. They MUST NOT appear as a reason to skip sink consume.
14.10. What This Profile Does Not Require
It does not require replacing SWIFT, cards, or ISO 20022. It does
not require a blockchain on the posting path. It does not require
the model to detect fraud. It does not require every micropayment to
do remote attestation. It requires that the component which can
change a balance refuse to do so without current, consumed, digest-
bound authority.
15. Cross-Border, FX, and Split Legs
An FX payout is two load-bearing facts: the debit in currency C1 and
the credit in currency C2 toward a beneficiary in administration J.
Implementations MAY model this as one Candidate Act whose digest
includes both amounts, both currencies, the FX rate or rate source
epoch, and J, or as two acts that MUST NOT settle independently if
the business meaning is a single payout. Silent settlement of only
Das Expires 13 March 2027 [Page 27]
Internet-Draft Payment Execution Finality September 2026
the cheap leg is a substitution.
Correspondent or cover payments MUST NOT inherit authority issued for
the customer credit. A cover bank is another sink. Authority sink-
bound to core-post-eu-1 MUST fail at correspondent-post-us-9 unless a
new act is authorized.
16. Dual Control and Threshold Authority
Where policy requires maker-checker, the PED MUST treat missing
checker shares as validation failure, not as a warning. Shares MAY
be human approvals, independent policy engines, or a k-of-n MAC. The
issued Payment Finality Authority SHOULD list the share identifiers.
The sink MUST reject an authority whose share set no longer meets k.
Agents do not replace the checker. An agent MAY be the maker. If an
agent is also allowed to be a checker, that fact MUST be explicit in
policy and SHOULD be excluded for FINANCIAL class above the hot
envelope. Dual control that lives only in a UI, while an API posts
without shares, is an alternate path and is non-conforming for that
API.
17. Threat Model
17.1. Trust Boundary and Adversary Capabilities
This profile assumes an adversary who can:
* compromise the Compute / Workload Plane — the model, agent, ERP,
checkout flow, or API caller that constructs a payment instruction
— including full control of its process, its tool-call arguments,
and any client-supplied idempotency key;
* steal or forge session-level credentials reaching that plane,
including OAuth tokens, API keys, agent seats, and 3-D Secure or
SCA session artifacts;
* inject or alter upstream content that a human or an agent reads
before constructing a Candidate Act, such as a vendor-change email
or a modified invoice;
* replay a previously observed instruction, signed message, or
idempotency key at a second acquirer, PSP, or sink;
* observe network traffic between the Compute / Workload Plane and
the Protected Enforcement Domain.
Das Expires 13 March 2027 [Page 28]
Internet-Draft Payment Execution Finality September 2026
This profile assumes an adversary cannot, absent a separate
compromise stated as out of scope below:
* forge a valid Payment Finality Authority without the Protected
Enforcement Domain's signing or MAC key;
* cause the Settlement Sink to accept an authority whose digest does
not match the live instruction it verifies against;
* cause the durable consume-state store to transition an already-
consumed authority back to unused.
The trust boundary therefore separates the Compute / Workload Plane,
which this profile treats as untrusted and fully attacker-reachable,
from the Protected Enforcement Domain and the Settlement Sink, which
this profile treats as protected. Everything upstream of the
Protected Enforcement Domain may be computed by, or under the
influence of, an attacker; nothing downstream of it becomes
externally effective without independent verification against a live
instruction and consumption of a scoped, single-use authority.
+-------------------------+ trust boundary +-------------------------+
| Compute / Workload | | | Protected Enforcement |
| Plane (UNTRUSTED) | | | Domain (TRUSTED) |
| | | | |
| agent, model, ERP, | ----> | ----> | validate predicates |
| API caller | | | commit evidence |
| | | | issue scoped authority |
| produces: | | | |
| Candidate Act | | | |
| (NON_EFFECTIVE) | | | |
+-------------------------+ | +-------------------------+
| |
| v
| +-------------------------+
| | Settlement Sink |
| | (TRUSTED) |
| | |
| | verify live digest |
| | vs authority |
| | atomic consume + post |
| | or fail-closed deny |
| +-------------------------+
An instruction that never crosses the trust boundary with matching
evidence and unused authority cannot become externally effective,
regardless of what the attacker was able to do on the untrusted side.
Das Expires 13 March 2027 [Page 29]
Internet-Draft Payment Execution Finality September 2026
17.2. Out-of-Scope Threats
This profile does not defend against, and does not claim to mitigate:
* compromise of the Protected Enforcement Domain's signing or MAC
key itself, including key exfiltration from a software-only HMAC
deployment (Section 14 discusses hardware- backed alternatives);
* a colluding or compromised Settlement Sink operator who chooses
not to verify, or who verifies against a falsified live
instruction it controls;
* social engineering that occurs before the Candidate Act is
constructed, such as convincing an authorized human to approve a
fraudulent beneficiary in the first instance; the profile binds
what was approved, not whether the approval itself was well-
founded;
* compromise of upstream identity or credential issuance that causes
the Protected Enforcement Domain to accept a forged agent or
workload identity as genuine;
* multi-sink deployments that share consume state incorrectly, such
that two independently protected sinks each treat a single-use
authority as unused;
* denial of service against the Protected Enforcement Domain or
Settlement Sink;
* compliance failures in sanctions, AML, or beneficiary-risk
screening systems that feed a predicate into the Protected
Enforcement Domain, beyond binding the screen's epoch or list
identifier as stated in Section 23.
These are stated explicitly because a profile that is silent on its
own limits invites reviewers to assume broader coverage than the
architecture provides.
17.3. Threat-to-Mitigation Mapping
Each threat in Section 18 is mapped below to the architectural
control that defeats it and the residual risk that remains after the
control is applied.
Das Expires 13 March 2027 [Page 30]
Internet-Draft Payment Execution Finality September 2026
+===============+================================+==================+
|Threat |Defeated by |Residual risk |
+===============+================================+==================+
|T1 Stolen PSP/ |Token authenticates a client |Attacker who also |
|core API token |only; digest-bound scoped |compromises the |
| |authority is still required at |PED validation |
| |the sink |path |
+---------------+--------------------------------+------------------+
|T2 Stolen agent|Agent/workload identity bound |Attacker who |
|seat with |into digest and authority; sink |compromises the |
|payout tools |checks holder binding |same agent/ |
| | |workload identity |
| | |itself |
+---------------+--------------------------------+------------------+
|T3 Injected |Beneficiary identity/account |Social engineering|
|invoice / |load-bearing in digest; PED |before Candidate |
|vendor-change |beneficiary-risk predicate |Act construction |
|mail | |(out of scope) |
+---------------+--------------------------------+------------------+
|T4 Amount |Amount normalized and load- |Compromised |
|substitution |bearing; sink reconstructs and |canonicalization |
|after approval |compares live digest |implementation or |
| | |PED/sink collusion|
+---------------+--------------------------------+------------------+
|T5 Beneficiary |Beneficiary ID and account load-|Compromised PED |
|substitution / |bearing; digest mismatch denies |signing/MAC key |
|BEC | |(out of scope) |
+---------------+--------------------------------+------------------+
|T6 Rail |Rail is a load-bearing field; |Sink |
|substitution |different rail invalidates the |implementation |
| |authority |defect that skips |
| | |rail comparison |
+---------------+--------------------------------+------------------+
|T7 Replay on |Sink-bound, single-use |Multi-sink |
|second |authority; consume-once state |deployments |
|acquirer/PSP |keyed by digest and authority ID|sharing consume |
| | |state incorrectly |
| | |(out of scope) |
+---------------+--------------------------------+------------------+
|T8 Idempotency-|Consume table keyed by |Non-conformant |
|key reuse with |instruction digest and authority|implementation |
|new body |ID, not client string |that still trusts |
| | |a client |
| | |idempotency key |
| | |alone |
+---------------+--------------------------------+------------------+
|T9 Mandate used|Purpose/mandate ID load-bearing;|Compromised |
|off-purpose |PED mandate predicate |mandate policy |
Das Expires 13 March 2027 [Page 31]
Internet-Draft Payment Execution Finality September 2026
| | |data itself |
+---------------+--------------------------------+------------------+
|T10 Payroll |One-row-equals-one-Candidate-Act|Batch/manifest |
|file row |model; per-row digest |profile for |
|injection | |partial settlement|
| | |not yet specified |
| | |(Section 7) |
+---------------+--------------------------------+------------------+
|T11 FX-leg |FX fields load-bearing where |Current profile |
|split to move |modeled; linked-act requirement |models one leg |
|value cheaply | |only, no atomic |
| | |cross-sink |
| | |settlement |
| | |(Section 7) |
+---------------+--------------------------------+------------------+
|T12 Risk-list |Risk-list epoch bound into |Compromise of the |
|epoch rollback |authority; stale epoch |epoch source |
| |invalidates unused authority |itself |
+---------------+--------------------------------+------------------+
|T13 Checker UI |Dual-control predicate enforced |PED misconfigured |
|bypass via API |at the PED, not only at the UI |to treat the API |
| | |path as pre- |
| | |approved |
+---------------+--------------------------------+------------------+
|T14 Agent A |Agent/workload identity bound |Shared credential |
|authority used |into digest and authority; sink |material between |
|by agent B |checks holder match |agents (identity- |
| | |issuance flaw, out|
| | |of scope) |
+---------------+--------------------------------+------------------+
|T15 Refund used|Act type (capture vs. refund) |Incorrect act-type|
|as origination |load-bearing; distinct Candidate|classification at |
| |Acts |construction time |
+---------------+--------------------------------+------------------+
Table 1
18. Payment Threat Catalog
* T1 Stolen PSP or core API token
* T2 Stolen enterprise agent seat with payout tools
* T3 Injected invoice or vendor-change mail
* T4 Amount substitution after UI approval
* T5 Beneficiary substitution / BEC
Das Expires 13 March 2027 [Page 32]
Internet-Draft Payment Execution Finality September 2026
* T6 Rail substitution (on-us to instant)
* T7 Replay on a second acquirer or PSP
* T8 Idempotency-key reuse with new body
* T9 Mandate used off-purpose
* T10 Payroll file row injection
* T11 FX-leg split to move value cheaply
* T12 Risk-list epoch rollback
* T13 Checker UI bypass via API
* T14 Agent A authority used by agent B
* T15 Refund used as origination
The protocol does not require the model to label these attacks. It
requires post_to_rail() to be unreachable when the corresponding bind
fails.
19. Additional Worked Denials
{
"scenario": "BEC_BENEFICIARY_SWAP",
"authorized": {
"amount": "150.00",
"currency": "EUR",
"beneficiary_id": "vendor-441"
},
"live": {
"amount": "150.00",
"currency": "EUR",
"beneficiary_id": "attacker-992"
},
"sink": {
"decision": "DENY",
"code": "EF_BENEFICIARY_MISMATCH",
"posted": false
}
}
Das Expires 13 March 2027 [Page 33]
Internet-Draft Payment Execution Finality September 2026
{
"scenario": "REPLAY_SECOND_PSP",
"authority_id": "pfa-88c0",
"first_sink": {
"sink_id": "core-post-eu-1",
"status": "CONSUMED"
},
"second_sink": {
"sink_id": "psp-alt-2",
"decision": "DENY",
"code": "EF_SINK_MISMATCH"
}
}
{
"scenario": "AGENT_AMOUNT_ENVELOPE",
"hot_ceiling": "500.00",
"requested": "5000.00",
"decision": "DENY",
"code": "EF_AMOUNT_ENVELOPE",
"remediation": "ESCALATE_TO_CHECKER"
}
20. Regulatory and Operational Notes
This document does not claim to satisfy PSD2, SCA, PCI DSS, AML, or
sanctions-screening obligations. Those systems produce inputs (SCA
result, screening epoch, card-data scope) that the PED MAY require.
A clean screening result is not settlement authority for a
substituted beneficiary.
Operations staff SHOULD log authority_id, instruction_digest, consume
time, and settlement_ref together. That tuple is what a scheme or
correspondent will ask for after a dispute. Logging the model prompt
instead of the digest is not a substitute.
21. Failure Codes and Denial Behavior
Illustrative codes, not IANA assignments: EF-002
NO_FINALITY_AUTHORITY, EF-005 AUTHORITY_ALREADY_USED, EF-006
REPLAY_DETECTED, EF-023 INSTRUCTION_SUBSTITUTION, EF-024
AMOUNT_MISMATCH, EF-025 BENEFICIARY_MISMATCH, EF-026 RAIL_MISMATCH,
EF-027 MANDATE_MISS, EF-028 PAYEE_BLOCKED, EF-029 AMOUNT_ENVELOPE,
EF-040 SINK_MISMATCH, EF-070 ESCALATION_REQUIRED, EF-080 FAIL_CLOSED.
A denial MAY name a remediation (re-quote amount, escalate checker,
refresh risk list) but MUST NOT post. Timeout MUST NOT post.
Das Expires 13 March 2027 [Page 34]
Internet-Draft Payment Execution Finality September 2026
22. Combined Agent Tool Call and Payment Act
When the instruction is born as a model tool call, two objects SHOULD
be created from the same canonical arguments:
{
"agent_candidate_act": {
"object_type": "agent_candidate_act",
"act_type": "TOOL_CALL",
"tool": {
"tool_id": "payout.create",
"function_id": "create",
"tool_protocol": "MCP"
},
"arguments_digest": {
"algorithm": "SHA-256",
"value": "base64url-args"
},
"consequence_class": "FINANCIAL",
"finality_sink": {
"sink_id": "mcp-dispatch-1",
"sink_type": "TOOL_DISPATCH"
}
},
"payment_candidate_act": {
"object_type": "payment_candidate_act",
"act_type": "PAYOUT",
"amount": "150.00",
"currency": "EUR",
"beneficiary": { "beneficiary_id": "vendor-441" },
"rail": { "rail_id": "SEPA_INSTANT" },
"instruction_digest": {
"algorithm": "SHA-256",
"value": "base64url-ins-digest"
},
"finality_sink": {
"sink_id": "core-post-eu-1",
"sink_type": "CORE_POST"
}
},
"rule": "dispatch sink may run the tool handler; posting sink may move funds; neither check replaces the other"
}
If only the tool dispatcher checks, a handler bug can still post. If
only the posting sink checks, a different tool (raw HTTP to the PSP)
can still fire. Alternate-path closure requires both for agent-
originated value movement.
Das Expires 13 March 2027 [Page 35]
Internet-Draft Payment Execution Finality September 2026
23. Security Considerations
Threats the sink is intended to make non-completable without current
authority include: amount and payee substitution, rail laundering,
replay across PSP and core, stolen agent seat, injected invoice,
mandate over-use, risk-list staleness, and a second path (manual file
drop) that posts the same funds.
If the Settlement Sink holds unrestricted posting rights and skips
verification, the profile collapses for that path. High-assurance
deployments SHOULD keep authority-signing keys off the agent host and
SHOULD treat payment class as cold-path default above a ceiling.
Idempotency keys supplied by the client are not consume-once
authority. An attacker who can change the body and keep the key, or
who can mint a new key for the same digest after consume, is out of
scope for "we already have idempotency." The consume table MUST be
keyed by instruction digest and authority_id, not only by a client
string.
Sanctions and AML screens are necessary and insufficient. A clean
screen of beneficiary-441 does not authorize a post to attacker-992.
Screen results SHOULD be bound into PED evidence as an epoch or list
identifier so a later list update invalidates unused authority.
24. Privacy Considerations
Instruction objects carry account references and payee identifiers.
Implementations SHOULD hash account numbers in logs and SHOULD prefer
account_digest in authority objects that leave the posting host.
Cross-border acts MUST treat beneficiary jurisdiction as a load-
bearing field, not as telemetry.
25. Relevance to IETF Working Groups
No current IETF working group owns settlement-sink admission control
for payment instructions specifically, so this document is filed as
an individual submission pending a dispatch decision. The following
existing groups and their outputs bound adjacent, but distinct, parts
of the problem:
* SECDISPATCH: the appropriate routing venue for a new security
problem statement that does not have an obvious home. This
document is a candidate for a SECDISPATCH presentation asking
whether payment-side execution finality should become chartered
work, and if so, in which group.
Das Expires 13 March 2027 [Page 36]
Internet-Draft Payment Execution Finality September 2026
* GNAP (Grant Negotiation and Authorization Protocol): GNAP
delegates and negotiates authorization grants between a client and
a resource; it is the closest existing analog to scoped, non-
bearer authority issuance. It does not specify a digest-bound,
single-use capability that a settlement sink independently
reconstructs and verifies against a live instruction, which is the
gap this document addresses.
* OAUTH: bearer and sender-constrained tokens (RFC 8693, DPoP, mTLS-
bound tokens) authenticate a client or session. Section 5
explains why token possession is not equivalent to act-specific,
amount-bound authority at the point funds actually move.
* SCITT (Supply Chain Integrity, Transparency, and Trust): SCITT's
transparency-service and signed- statement model is structurally
close to this document's evidence-before-authority ordering
(Section 9). A SCITT-style receipt could serve as the durable
evidence artifact the Protected Enforcement Domain commits before
issuing authority; this document does not currently depend on
SCITT and notes the alignment for future harmonization.
* RATS (Remote ATtestation procedureS): where the Protected
Enforcement Domain or Settlement Sink runs in an attested
environment, RATS conceptual messages (Evidence, Endorsement,
Attestation Result) can supply one input predicate to the finality
decision. This document treats attestation as an optional
predicate, not a substitute for digest-bound, consume-once
authority; see also [I-D.das-6g-finality] for the companion
attestation-adjacent profile.
* STIR/SHAKEN and related identity-assurance work: provide caller
and channel identity assurance in adjacent telecom signaling
contexts. They are cited here only to distinguish channel-
identity assurance from act-specific, amount-bound settlement
authority, which is this document's subject.
This document does not ask any of the above groups to adopt it as-is.
It is offered as an input problem statement so that chairs and area
directors can decide whether the work belongs in an existing group, a
new SECDISPATCH-routed effort, or remains an informational individual
submission.
26. Implementation Checklist
A deployment may call itself aligned with this profile when all of
the following are true on the covered rail:
Das Expires 13 March 2027 [Page 37]
Internet-Draft Payment Execution Finality September 2026
1. Every post has an authority_id that was consumed atomically with
the post.
2. Instruction digest covers amount, currency, beneficiary, and
rail.
3. Amount, payee, or rail mismatch is a deny, not a log line.
4. Replay at a second sink fails.
5. Timeout does not post.
6. Agent payout tools cannot reach the PSP SDK without the sink
function.
7. Added hot-path latency is measured and sits in the 1-10 ms class
or is explained.
8. Legacy paths that can emit the same clearing message are
inventoried; those not yet gated are listed as known alternate
paths with a closure date.
27. IANA Considerations
This document requests no IANA actions.
28. Intellectual Property and Licensing
Concepts in this profile are associated with the DAS Protocols
family, including International Application PCT/IB2026/055615. IETF
disclosure should follow BCP 79 [RFC8179].
By default, the reference-implementation repository accompanying this
document (Section 29) is licensed under the Creative Commons
Attribution-NonCommercial 4.0 International (CC BY-NC 4.0) licence.
Attribution is required, and commercial use is not permitted without
separate written permission.
Associated patent rights, including those relating to the DAS
Protocols family and PCT/IB2026/055615, are not licensed under CC BY-
NC 4.0. Commercial implementation of the profile described in this
document may require a separate patent licence.
Should this specification, or a specification derived from it, become
IETF-standardized work (see Section 25), the default patent licensing
basis for that standardized specification is Fair, Reasonable, and
Non-Discriminatory (FRAND) terms, consistent with the disclosure
obligations of BCP 79 [RFC8179]. Any commercial patent licence
Das Expires 13 March 2027 [Page 38]
Internet-Draft Payment Execution Finality September 2026
offered for implementations of an IETF-standardized version of this
specification will be offered on FRAND terms. The CC BY-NC 4.0
licence governs copyrightable material only, namely the text of this
document and the reference-implementation source code; it does not
itself constitute, extend, or limit any patent licence, and it does
not alter the FRAND commitment applicable to an IETF-standardized
version of this specification.
29. Reference Implementation
A runnable, vendor-neutral reference implementation of this profile
is maintained outside this document. Full architecture notes, source
layout, cryptographic and canonicalization choices, test coverage,
benchmark methodology, failure codes, and stated limitations are
documented at the GitHub implementation reference summary URL below
(https://github.com/sangmdas/Payment-Execution-Finality-for-Agentic-
API-and-Automated-Payments-Runnable-Reference-Implementation
(https://github.com/sangmdas/Payment-Execution-Finality-for-Agentic-
API-and-Automated-Payments-Runnable-Reference-Implementation));
readers should consult that repository, not this section, for
implementation-level detail.
In summary, the reference implementation:
* is written in Python 3.10 or newer and reproduces the Payment
Candidate Act, Protected Enforcement Domain, scoped non-bearer
authority, and Settlement-Sink verify-and-consume flow defined in
this document;
* uses HMAC-SHA-256 behind a replaceable authenticator interface,
SQLite for durable consume-once state, and a restricted
canonicalization profile (EF-JCS-SUBSET-1) for the load-bearing
payment projection and instruction digest;
* ships a cross-language test vector (test-vectors/ef-pay-1.json) so
independent language ports can verify digest interoperability
before claiming conformance;
* includes 52 executable tests covering amount normalization,
instruction substitution, replay and concurrency, epoch and
expiration freshness, and rail failure classification (definite
vs. uncertain);
* reports a local reference benchmark (p50/p95/p99 per stage)
consistent with the target latency class in Section 14, measured
on an in-memory store and a simulated, non-effecting rail adapter;
and
Das Expires 13 March 2027 [Page 39]
Internet-Draft Payment Execution Finality September 2026
* is explicitly not a certified payment system: it does not
integrate a live rail, does not claim HSM-grade key isolation, and
does not claim regulatory or PCI DSS compliance. See the
repository's own limitations documentation for the full list.
The repository is licensed under CC BY-NC 4.0 by default, per
Section 28. Patent rights are addressed separately from the
copyright licence; see Section 28 for the FRAND commitment applicable
if this specification becomes IETF-standardized work.
This document is part of a related family of execution-finality
Internet-Drafts by the same author, applying the same Candidate Act /
Protected Enforcement Domain / Finality Sink architecture to other
domains. Readers evaluating this profile may also find the following
relevant:
* draft-das-agentic-tool-binding (https://datatracker.ietf.org/doc/
draft-das-agentic-tool-binding/) — binds execution finality to
tool_use/function-calling and MCP dispatch;
* draft-das-execution-finality-protocol-layer
(https://datatracker.ietf.org/doc/draft-das-execution-finality-
protocol-layer/) — umbrella/synthesis draft formalizing the shared
vocabulary (Candidate Act, Non-Effective State, Protected
Enforcement Domain, Finality Sink) used across the family;
* draft-das-eu-ai-act-execution-enforcement
(https://datatracker.ietf.org/doc/draft-das-eu-ai-act-execution-
enforcement/);
* draft-das-global-privacy-execution-enforcement
(https://datatracker.ietf.org/doc/draft-das-global-privacy-
execution-enforcement/);
* draft-das-digital-sovereignty-finality
(https://datatracker.ietf.org/doc/draft-das-digital-sovereignty-
finality/);
* draft-das-ntn-rf-execution-finality
(https://datatracker.ietf.org/doc/draft-das-ntn-rf-execution-
finality/);
* draft-das-payment-execution-finality
(https://datatracker.ietf.org/doc/draft-das-payment-execution-
finality/) — this document's own datatracker entry, listed here
for completeness of the series;
Das Expires 13 March 2027 [Page 40]
Internet-Draft Payment Execution Finality September 2026
* draft-das-agentic-execution-finality
(https://datatracker.ietf.org/doc/draft-das-agentic-execution-
finality/);
* draft-das-ot-actuation-finality (https://datatracker.ietf.org/doc/
draft-das-ot-actuation-finality/);
* draft-das-protocols-candidate-act-finality
(https://datatracker.ietf.org/doc/draft-das-protocols-candidate-
act-finality/);
* draft-agentic-ai-tool-execution-finality
(https://datatracker.ietf.org/doc/draft-agentic-ai-tool-execution-
finality/) (no "das-" prefix); and
* draft-das-hardware-enforced-execution-finality
(https://datatracker.ietf.org/doc/draft-das-hardware-enforced-
execution-finality/).
Links above point to each draft's datatracker overview page, which
always resolves to the current revision, rather than to a specific
dash-numbered version.
30. Conclusion
Rails move money. Agents and APIs now write the instruction. A
signature on the channel, a token on the worker, or a mandate on the
vendor is not authority for this amount to settle toward this
beneficiary on this rail now. Bind the digest. Commit evidence.
Consume at the posting sink. A signed instruction is not settlement.
31. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
[RFC8179] Bradner, S. and J. Contreras, "Intellectual Property
Rights in IETF Technology", BCP 79, RFC 8179, May 2017,
<https://www.rfc-editor.org/info/rfc8179>.
32. Informative References
Das Expires 13 March 2027 [Page 41]
Internet-Draft Payment Execution Finality September 2026
[I-D.das-6g-finality]
Das, S., "Execution-Finality for AI-Native 5G/6G and
O-RAN", Work in Progress, Internet-Draft, draft-das-ai-
native-6g-execution-finality-01, August 2026,
<https://datatracker.ietf.org/doc/html/draft-das-ai-
native-6g-execution-finality-01>.
[I-D.das-agentic]
Das, S., "Tool Selection Is Not Execution: Finality for
Agentic Tool Dispatch", Work in Progress, Internet-Draft,
draft-das-agentic-execution-finality-01, August 2026,
<https://datatracker.ietf.org/doc/html/draft-das-agentic-
execution-finality-01>.
Author's Address
Sangam Das
Independent Inventor
Balasore 756001
Odisha
India
Email: info@sangamdas.com
Das Expires 13 March 2027 [Page 42]