The financial system was built for humans. Slow ones. Ones who sleep, work business hours in one time zone, fill out forms in triplicate, and accept without particular frustration that a wire transfer takes one to two business days. The entire architecture — from clearing house batch windows to fraud detection models to KYC processes to settlement finality conventions — was designed around the premise that the transacting parties are human beings with human-speed requirements.
AI agents are operating on entirely different parameters. An agent managing a corporate treasury might initiate 10,000 micro-payments in an hour. A research agent coordinating a multi-step information gathering task might pay 50 different API endpoints within a single tool-use cycle. An accounts payable agent running at enterprise scale might verify invoice conditions, confirm budget approval, check counterparty details against sanctions lists, and execute payment — 500 times in a working day without any human initiating individual transactions.
What happens when you run these workloads through traditional financial infrastructure? Not slow results or inconvenience. Actual system failures — fraud flags, rate limits, batch processing delays that break the logic of autonomous workflows, and fundamental incompatibilities with the requirements of non-human transacting parties.
Credit cards — designed for human authentication
The credit card model requires a human cardholder, a billing address, a CVV, and a name. The authentication model — presenting credential information that only the legitimate cardholder should have — is built around human knowledge and possession factors. The fraud detection models are calibrated on human spending patterns: geographic velocity, merchant category patterns, transaction frequency.
The virtual card models that have emerged for programmatic payments improve the developer experience but don't resolve the fundamental architecture problem. A virtual card is still tied to a human's card account. The agent borrows spending authority from a human financial identity — it doesn't have its own. When the agent spends at machine velocity, human-calibrated fraud models trigger. When the agent needs to transact in a way that exceeds the cardholder's pre-configured limits, it requires human intervention. The constraint is architectural, not configuration.
Bank accounts — KYC for humans only
Opening a bank account requires a legal person. A natural person (human being) or a legal entity (corporation, LLC, partnership). AI agents are neither. They can't sign account agreements. They can't appear for KYC verification. They can't hold property in their own name in virtually any jurisdiction.
The workaround — having an agent operate as an authorized signatory on a human or corporate account — reintroduces the proxy model problems. The transactions are attributed to the account holder, not to the agent. The limits and fraud detection are calibrated for the account holder's expected behaviour. When hundreds of agents share access to a corporate account, the audit trail is a mess of automated transactions attributed to the company rather than the specific agent that made each decision.
ACH and SWIFT — batch processing at human pace
ACH (Automated Clearing House) was built for batch processing. Transactions are aggregated, netted, and settled in batch windows — typically once or several times per business day. Same-day ACH was a significant improvement, but it still operates in discrete batch windows, not continuously. For an agent that needs to confirm payment received before taking a dependent action, batch settlement breaks the workflow logic entirely.
SWIFT operates similarly at the international level, with the added complexity of correspondent banking chains that introduce both delay and uncertainty. A SWIFT wire transfer might settle in hours or might take days depending on the correspondent network path. For autonomous agents coordinating actions with payment confirmation as a dependency, this is not workable.
The economics compound the problem. ACH has practical minimum transaction sizes where processing costs make very small payments economically negative. Sub-cent micropayments — the natural economics of agent-to-API access — are simply impossible on ACH. You can't pay $0.0001 per API call through a batch clearing system.
Payment processors — excellent for humans, wrong for agents
Stripe, Adyen, Braintree, and the other major payment processors are genuinely excellent infrastructure — for the use cases they were designed for. Accepting card payments from human customers. Processing payroll disbursements to human employees. Managing subscription billing for human subscribers.
None of them were designed for a non-human principal transacting at machine scale with programmable spend policies and real-time settlement requirements. The API models work well for developer integration, but the underlying settlement infrastructure, compliance framework, and account model all assume a human on at least one side of every transaction. The onboarding processes, the dispute resolution mechanisms, the fraud detection — all calibrated for human commerce.
The assumption problem — why patches don't work
The failure mode of traditional infrastructure for agent workloads isn't a collection of fixable bugs. It's a coherent set of design assumptions that were correct for the original use case and are wrong for the new one:
- There is a human at the end of every transaction (wrong for agent-to-agent commerce)
- Settlement latency of hours to days is acceptable (wrong for agents with payment-dependent workflows)
- Transaction minimums of cents or dollars are reasonable (wrong for sub-cent API micropayments)
- Fraud detection should flag machine-velocity transaction patterns (wrong for legitimate agent workloads)
- Account ownership requires a legal person (wrong for agent wallets)
You can't patch your way out of wrong assumptions. You can add layers of workarounds — virtual cards, sub-accounts, flagging exceptions to fraud detection — but each workaround adds operational complexity and introduces new failure modes. The right solution is infrastructure built from different starting assumptions.
What agent-native infrastructure looks like
Agent-native financial infrastructure starts from the correct set of assumptions: agents are the transacting parties; settlement needs to be near-instant; sub-cent economics must work; fraud detection must accommodate machine-velocity legitimate workloads; the compliance framework must handle non-human financial identities.
This is what Proco is built for. Non-custodial agent wallets with cryptographic identity not tied to a human account. USDC settlement on Base with ~8-second finality. Transaction economics that work at fractions of a cent. Policy engines that define legitimate agent behaviour rather than treating machine velocity as suspicious. KYA compliance that handles non-human transacting parties through ownership-chain verification rather than individual person KYC.
Not payment infrastructure retrofitted for agents — built purely for them. The legacy rails break under agent load by design. The solution is infrastructure that was designed for this load from the start.
Further reading: The Agentic Finance Stack — A Developer's Blueprint · Why Non-Custodial Architecture Wins