EU AI Act + DORA: The Compliance Checklist for Agentic Payment Builders
Legal firms have published excellent coverage of what’s at risk under the EU AI Act for agentic payment systems. What’s missing is the practical guide for what to actually build. The August 2, 2026 enforcement deadline is less than five months away. If you’re building agentic payment infrastructure that touches EU users, the compliance window is closing.
This post translates EU AI Act and DORA requirements into a concrete implementation checklist. It assumes you’ve already read agent safety foundations and understand the baseline. This goes deeper on the compliance-specific requirements.
The short answer
Compliance for agentic payment systems under EU AI Act and DORA means implementing four categories of control: audit trails (every transaction logged with agent identity and authorization chain), spending controls enforced at infrastructure level, revocation mechanisms for agent credentials, and documented human override procedures. These aren't guidelines — they're enforceable requirements from August 2, 2026 for systems operating in or serving the EU.
The risk-based framing of the EU AI Act creates a common misconception: that only “high-risk” AI systems need serious compliance work. In practice, most production agentic payment systems will require meaningful compliance investment regardless of risk tier — because the minimum requirements for any AI system touching financial transactions are not trivial.
EU AI Act + DORA: What Agentic Payment Builders Must Know
The EU AI Act’s full application date is August 2, 2026. DORA has been operational since January 17, 2025 — meaning DORA compliance for existing payment service providers is already overdue if not in place (Taylor Wessing, February 2026).
EU AI Act risk tiers for payment systems:
The Act uses a risk-based structure. Where your agentic payment system lands depends on what it does:
| AI System Function | Likely Risk Tier | Key Requirements |
|---|---|---|
| Creditworthiness assessment | High-risk | Conformity assessment, human oversight, audit logs, explainability |
| Autonomous purchase execution | Medium-risk | Transparency obligations, human override documentation |
| Fraud detection | High-risk (financial) | Conformity assessment, bias testing, audit trails |
| General task execution with payments | Medium-risk | Transparency, meaningful human control |
| Agent-to-agent internal settlement | Lower-risk | Standard transparency requirements |
Payment Service Providers are classified as “users” of AI systems — subject to less stringent obligations than AI providers building the underlying models. But “less stringent” doesn’t mean “none.” PSPs still need to implement human oversight, document AI system usage, conduct due diligence on AI vendors, and report incidents.
DORA requirements for agentic payment infrastructure:
DORA creates mandatory ICT risk management requirements. For agentic payment systems, the relevant obligations:
- Minimum contractual requirements in agreements with AI system providers (what SLAs, incident notification, audit rights you must contractually secure)
- Comprehensive due diligence on AI infrastructure providers before deployment
- Integration of external AI products into the organization’s ICT risk management framework
- Incident classification and reporting for AI-related payment disruptions
The intersection is important: DORA requires you to manage the risk of AI vendors; EU AI Act requires you to ensure the AI systems you deploy (even those built by vendors) meet compliance standards. Both frameworks point in the same direction: you can’t outsource compliance by pointing at your AI vendor.
The August 2026 Deadline: What Changes and When
Not all EU AI Act provisions apply on the same date. The timeline matters for compliance planning:
| Provision | Application Date |
|---|---|
| General-purpose AI model obligations | August 2, 2025 (already active) |
| Prohibited AI practices | February 2, 2025 (already active) |
| High-risk AI systems (Annex III) | August 2, 2026 |
| Other AI systems + obligations | August 2, 2026 |
| Certain high-risk systems (Annex I) | August 2, 2027 |
The August 2, 2026 deadline is the most significant for agentic payment builders: this is when high-risk AI system requirements and general AI obligations become enforceable for most payment-adjacent AI applications. With a five-month window remaining, teams that haven’t started compliance work are behind.
DORA enforcement is not tiered by date in the same way — it applies to financial entities regulated under EU financial services law, with the digital operational resilience requirements operative since January 2025.
The 12-Point Compliance Checklist for Agentic Payment Systems
This checklist reflects EU AI Act requirements (meaningful human control, transparency, incident reporting) and DORA requirements (ICT risk management, vendor due diligence, resilience testing). Each item maps to enforceable obligations, not best practices.
Audit and Logging
-
Audit logging for every agent transaction. Every transaction must be logged with: timestamp, agent identifier, action taken, amount, authorization source, and outcome. Logs must be tamper-resistant and retained per applicable data retention requirements.
-
Agent identity recorded with each transaction. The log entry must identify which agent took the action — not just which user account authorized it. Human-credential logging is insufficient for AI Act transparency requirements when the transaction was agent-initiated. See zero-trust architecture for agents for identity architecture patterns.
-
Authorization chain logged. Who authorized what, at what time, through what mechanism. For multi-agent systems, this means logging the full delegation chain: human principal → orchestrator → sub-agent → transaction.
Human Control
-
Human override mechanism documented and tested. The AI Act’s meaningful human control requirement demands a documented, tested procedure for humans to halt, modify, or reverse agent transactions. “Documented” means it exists in writing; “tested” means you’ve verified it works.
-
Spending limits enforced at infrastructure level (not application level). Application-code spending limits are insufficient for compliance purposes — an agent with a bug or under adversarial prompt injection can route around software-level checks. Limits must be enforced at the infrastructure layer where the agent cannot override them. ATXP’s credit system enforces limits at the account level, not the application level.
-
Regular audit of agent permissions and limits. Static limits set at deployment become stale as agent workloads evolve. Document a review cadence and audit record. Quarterly is a reasonable minimum for most deployments.
Security and Revocation
-
Revocation mechanism for agent credentials. The ability to immediately revoke an agent’s payment authorization — without waiting for a transaction to complete or a session to end. Credential isolation and revocation covers the architecture; the compliance requirement is that this mechanism exists, is tested, and is documented.
-
Transaction anomaly detection in place. Real-time or near-real-time detection for unusual transaction patterns: volume spikes, unusual merchants, out-of-hours activity, transactions outside the agent’s intended use scope. This satisfies the AI Act’s requirement for monitoring systems for high-risk AI applications.
-
Data residency compliance for transaction logs. Transaction logs may contain personal data subject to GDPR, and DORA has specific requirements around ICT data management. Verify that audit logs are stored in compliant locations for the jurisdictions you operate in.
Vendor and Third-Party Risk
-
Third-party vendor compliance verification. DORA requires due diligence on AI system providers. For each AI vendor in your payment stack, document: what AI Act obligations they have met, what contractual protections you have, and how you’d respond if they fail compliance.
-
Incident response procedure documented. A documented procedure for AI-related payment incidents: what counts as an incident, who is notified, what is the remediation process, what is reported to regulators. DORA has specific incident reporting requirements for significant ICT incidents at financial entities. See also: incident response for agent transactions.
Liability
- Clear liability documentation between human principal and agent. When an AI agent makes an unauthorized or erroneous payment, who is liable? The human principal, the AI system provider, the payment infrastructure? This must be documented in terms of service, user agreements, and internal policy — both to satisfy AI Act transparency requirements and to protect the business in disputes.
How Spending Limits + Audit Trails Satisfy “Meaningful Human Control”
The EU AI Act’s meaningful human control requirement is not prescriptive about implementation — it specifies the outcome (humans can understand, monitor, and intervene) rather than the mechanism. Spending limits and audit trails are the two clearest architectural implementations.
Spending limits → intervention capability. If an agent’s spending authority is limited to $X per session or $Y per day, the worst-case outcome of a malfunction or compromise is bounded. A human principal reviewing the account the next day can identify overspend and take action. The limit doesn’t prevent mistakes, but it ensures mistakes are containable — which is the practical meaning of meaningful human control in a payment context.
Audit trails → understanding capability. Meaningful human control requires that humans can understand what the agent did. An audit trail that records agent identity, authorization chain, action, and outcome for every transaction gives a human reviewer the information needed to understand what happened and why. Without this, “human oversight” is nominal rather than meaningful.
The EU AI Act expects both to be in place. Neither alone is sufficient. Spending limits without audit trails means humans can contain damage but not understand it. Audit trails without spending limits mean humans can understand what happened but couldn’t have prevented it.
ATXP’s infrastructure provides both out of the box: per-session and per-agent spending limits enforced at the account level, and transaction logs accessible to the human principal. The compliance architecture is built into the product rather than requiring custom implementation.
What ATXP Provides Out of the Box
Building full compliance architecture from scratch is significant engineering work. For teams using ATXP, several of the 12 checklist items are handled at the infrastructure level:
- Items 1–3 (Audit logging, agent identity, authorization chain): ATXP logs every credit debit with agent identifier, timestamp, and action detail. The principal account has access to the full transaction history.
- Item 5 (Infrastructure-level spending limits): ATXP credit limits are enforced at the account level — the agent cannot spend beyond its allocated credits regardless of what the application code instructs.
- Item 7 (Revocation): ATXP accounts can be suspended immediately, halting all agent spending without requiring the agent’s process to be terminated.
- Item 8 (Anomaly detection): ATXP monitors for unusual transaction patterns and surfaces alerts to account holders.
Items that remain the developer’s responsibility regardless of infrastructure: human override documentation (Item 4), permission review cadence (Item 6), data residency for custom logs (Item 9), vendor due diligence on ATXP and other providers (Item 10), incident response procedures (Item 11), and liability documentation in user agreements (Item 12).
No infrastructure provider covers all 12 points — the liability and procedural items are inherently organizational. But infrastructure that handles items 1–3, 5, 7, and 8 reduces the custom compliance engineering surface significantly.
The August 2026 deadline is fixed. The checklist is knowable. The only variable is how much of the work gets done in time.
FAQ
Does the EU AI Act apply to agents that only make internal payments (not to external merchants)? The EU AI Act applies to AI systems based on their risk category and function, not based on whether payments are internal or external. An agentic system making internal financial decisions at scale — budget allocation, resource provisioning — could still fall under the Act’s requirements if it has significant impact on people or financial flows. Internal agent-to-agent settlement with sub-cent transactions between software components is lower risk; internal AI systems making significant financial allocation decisions are higher risk.
What is the penalty for EU AI Act non-compliance? Penalties are tiered by violation type. For non-compliance with obligations for high-risk AI systems, the maximum penalty is the higher of €15 million or 3% of global annual turnover. For prohibited AI practices, up to €35 million or 7% of global turnover. These apply to organizations operating in or serving the EU.
How does GDPR interact with agentic payment audit logs? Audit logs that include transaction data tied to identifiable individuals (human principals, end customers) are personal data under GDPR. This creates a retention management requirement: logs must be retained long enough for compliance audits but not indefinitely. Data residency requirements also apply. Building audit logging infrastructure for agentic payment compliance requires GDPR review as a co-requirement, not an afterthought.
What is the difference between EU AI Act compliance and PCI DSS compliance for agent payments? PCI DSS addresses payment card data security — how card credentials are stored, transmitted, and protected. EU AI Act compliance addresses AI system transparency, human oversight, and risk management. They’re overlapping but distinct obligations. An agentic payment system needs both: PCI DSS for card data security (if handling card credentials), and EU AI Act compliance for the AI decision-making layer. ATXP’s credit system reduces PCI scope by removing card credentials from the agent’s reach — but EU AI Act compliance obligations remain regardless.