Map roles before requirements
Document who is the principal, agent provider, merchant, marketplace, wallet provider, custodian, facilitator, processor, acquirer, issuer, and settlement participant. One company may occupy several roles, and obligations can change when it controls funds, selects counterparties, or holds reusable credentials.
The architecture diagram and legal analysis should describe the same flow. If product copy says a facilitator is non-custodial while operational design gives it unilateral control over assets, the implementation—not the copy—determines the risk.
Card data and tokenization
Keep primary card credentials out of the agent runtime. Use processor, network, or shared payment tokens that are limited to the intended seller and transaction. PCI DSS scope depends on how cardholder data is stored, processed, or transmitted; tokenization can reduce exposure but does not automatically remove every system from scope.
Preserve strong authentication, issuer controls, fraud signals, refund handling, and chargeback evidence. The fact that an approved agent initiated a transaction does not eliminate consumer-protection or dispute obligations.
Stablecoins, custody, sanctions, and AML
Stablecoin settlement can be fast and programmable, but the business still needs a custody model, asset and network policy, address screening, sanctions controls, accounting treatment, liquidity plan, and a refund process. Responsibilities vary substantially by jurisdiction and activity.
Wallet addresses are not complete customer identities. Risk systems may combine business identity, transaction context, wallet analytics, counterparty controls, and ongoing monitoring. Obtain qualified review before offering custody, exchange, transfer, or money-movement services.
Consent, disclosure, and recourse
The principal should understand the agent’s scope, the final economic terms, whether the transaction is recurring or irreversible, how to revoke authority, and how to obtain support. A natural-language mandate should be accompanied by normalized controls the user can inspect.
Receipts should identify the merchant, order, payment status, fulfillment state, and available refund or dispute path. Do not describe technical settlement as a completed purchase when the commercial outcome is still pending.
Compliance evidence should be generated by the flow
Store policy versions, verification results, mandate and credential references, screening decisions, order snapshots, rail identifiers, exceptions, and remediation. Access and retention should be purpose-limited, and secrets should be excluded from model traces and routine logs by design.
- Version the policies that approve or deny transactions.
- Record who or what performed step-up approval.
- Preserve screening inputs and outcomes without over-collecting data.
- Connect payment evidence to fulfillment, refunds, and disputes.
- Test revocation, data access, retention, incident response, and regulator-facing reconstruction.
This control map is technical information, not legal advice.
Source discipline
Primary sources
Product status and protocol behavior are checked against maintainer documentation. Company sources establish what their organizations publish; they do not independently prove adoption or performance.