The Examiner Question That Will Define Agentic Payments: 'Who Authorized This?'

Last month, an AI agent on Skyfire's platform sent $28,000 USDC to a wallet in Lagos at 3:14 AM Eastern. The agent was procuring data from a third-party API. It checked the invoice against its policy constraints, verified the destination wasn't on any blocklist, and executed the transfer. Nobody was awake.

Now imagine a BSA examiner reviewing this transaction six months from now. They ask the question that every compliance professional knows is coming: "Who authorized this?"

The honest answer is unsatisfying. Nobody authorized that specific payment. A developer wrote a policy file. A product manager approved the agent's spending limits. An LLM interpreted the policy and decided the invoice was legitimate. But nobody looked at this particular invoice, this particular wallet, this particular amount, and said "yes, send it."

This isn't a hypothetical problem for the future. Agentic payments are happening now. Skyfire processes real USDC payments through AI agent wallets. Skyfire's platform lets developers create a digital wallet for a large language model, then deposit funds into that wallet from a bank account or with USDC. Denso's AI agents are procuring auto parts autonomously. Citi Ventures is actively exploring the intersection of AI agents and payment networks. The rails exist. The compliance frameworks for those rails do not.

The authorization chain problem

When a human sends a wire, the authorization chain is unambiguous. Maria logged into the banking portal at 9:47 AM. She entered the beneficiary details. She reviewed the amount. She clicked "Send." There's a session log, an IP address, maybe a second factor authentication event. The authorization is traceable to a specific person making a specific decision at a specific time.

When an AI agent sends USDC, the authorization chain looks completely different. The "authorization" is a policy file written by a developer six months ago. The policy says something like: "Agent may approve vendor invoices up to $50,000 from wallets in the approved vendor registry." The LLM interprets that policy. It applies it to a transaction the developer never saw, for an amount the developer didn't specifically approve, to a wallet the developer may never have reviewed.

If the examiner asks "who authorized this specific payment?", the truthful answer is: "Nobody authorized this specific payment. Someone authorized the agent to make payments like this."

That distinction matters. A lot. BSA compliance is built on the concept of individual transaction authorization. When you file a SAR, you identify specific transactions and specific authorization events. When you respond to an examiner inquiry, you produce the approval chain for a specific payment. The entire framework assumes that someone, at some point, looked at this transaction and said yes.

With agentic payments, what you have instead is a delegation chain. The board delegated spending authority to the CFO. The CFO authorized the deployment of an autonomous treasury agent. The engineering team wrote a policy constraining the agent's behavior. The agent applied the policy to this transaction. Each link in that chain is defensible. But the chain is longer, less direct, and harder to document than "Maria clicked send."

The reasoning gap

BSA examiners routinely ask a second question: "Why was this transaction approved?"

For human-initiated payments, the answer lives in familiar places. Approval workflows. Email threads. Documented business purpose. "This was a quarterly payment to our Lagos supplier per contract #4471. The invoice was reviewed by accounts payable and approved by the finance director." Clean. Auditable. Stored in a system that nobody can quietly modify.

For agent-initiated payments, the "reasoning" is whatever the model computed at the time of the transaction. The agent evaluated the invoice. It checked the vendor registry. It compared the amount to the policy threshold. It decided the transaction was within scope. But unless you deliberately captured that reasoning at the moment of execution, it's gone.

This is the part that unsettles me. The model that made the decision may have been updated since then. The weights are different. If you ask the same model why it approved the transaction today, it might give you a different answer than it would have given at 3:14 AM six months ago. The reasoning is ephemeral unless you make it durable.

Agent reasoning capture is becoming a new compliance primitive. Not because regulators explicitly require it yet. But because the first examiner who asks "why did your agent approve this $28,000 transfer?" will expect a better answer than "the model thought it was fine." They'll want to see the specific policy that was applied, the specific inputs the model evaluated, and the specific output it produced. At the time of the transaction, not reconstructed after the fact.

If you're deploying agents that make payment decisions, you should be logging the agent's decision context for every transaction above your materiality threshold. The log should include the policy version, the inputs evaluated, the confidence score (if your model produces one), and the specific authorization determination. This log should be append-only. It should be timestamped. And ideally, it should be tamper-evident, so that six months from now you can prove the log hasn't been modified since the transaction.

The "subject" problem in SAR filing

FinCEN's SAR form has a field called "Subject Information." It asks for the person or entity conducting or attempting to conduct the suspicious transaction. Name, address, identification, role in the suspicious activity.

When a human conducts a suspicious transaction, the subject is the human. When a shell company conducts a suspicious transaction, the subject is the company and its beneficial owners. The form was designed for these scenarios.

When an AI agent conducts a suspicious transaction, who is the subject?

The agent itself? It doesn't have an identity in the regulatory sense. No SSN, no EIN, no address. The company that deployed it? They didn't initiate the specific transaction. The developer who wrote the policy? They defined the boundaries but didn't direct the action. The end user who triggered the workflow? In many agentic systems, there is no end user. The agent acts autonomously.

I've talked to compliance officers at three companies deploying agentic payment systems. All three are handling this differently. One lists the company as the subject and the agent as "acting on behalf of." Another lists the agent's identifier in the subject field and explains the relationship in the narrative. A third files with the company as subject and omits any reference to the agent, because they're worried that mentioning an AI agent will trigger additional scrutiny they're not prepared for.

None of them are confident they're doing it right. The GENIUS Act requires "appropriate operational, compliance, and information technology risk management principles-based requirements and standards, including Bank Secrecy Act and sanctions compliance standards." That language is broad enough to encompass agent-initiated transaction flows. It doesn't specifically address them. The gap between "broad enough to encompass" and "specifically addressed" is where enforcement risk lives.

The retroactive evidence problem

There's a fourth dimension to this that doesn't get enough attention. When an examiner reviews a suspicious transaction six months later, they need confidence that the records they're seeing are the same records that existed at the time of the transaction. They need to trust the evidence.

For human-initiated payments, institutional controls provide that confidence. Access logs show who touched the record. Separation of duties means the person who initiated the transaction can't modify the compliance records. Audit trails on the audit system itself create a chain of custody. These aren't perfect, but they're well-understood and examiners know how to evaluate them.

For agent-initiated payments, the picture is different. The agent's decision happened in software. The reasoning log is in a database. The compliance records are in another database. Anyone with database access could, in theory, modify what the agent "thought" six months ago. The traditional controls (access logs, separation of duties) still apply, but they're harder to enforce when the "actor" is software that runs across multiple systems.

Think about it from the examiner's perspective. They're looking at a transaction that an AI agent initiated at 3:14 AM. The company presents a reasoning log showing the agent checked the policy, screened the wallet, and determined the transfer was within scope. The examiner asks: how do I know this log wasn't created or modified after the transaction? How do I know the "reasoning" you're showing me is the reasoning the agent actually had, not a post-hoc reconstruction?

For traditional payments, nobody asks this question. The institutional controls are sufficient. For agent-initiated payments, the question is fair. The agent's reasoning is software output. Software output can be regenerated. Unless you've cryptographically committed to the reasoning at the time of the transaction, you can't prove it hasn't changed.

This is why tamper-evidence for agent transaction records is a harder problem than tamper-evidence for traditional payment records. It's not about the payment itself. It's about the decision that led to the payment. That decision happened in software, was produced by a model, and could theoretically be reproduced differently by a newer version of the same model. The evidence needs to be locked down at the time of creation, or it's not really evidence.

Where this leaves us

Compliance frameworks, BSA, OFAC, the Travel Rule, the GENIUS Act, were all written assuming a human initiates payments. They use words like "authorized," "intentional," "subject," and "conducted by." All of these concepts presume human agency. When an AI agent autonomously sends USDC to a wallet at 3 AM because its policy engine decided an invoice was valid, every one of those concepts gets fuzzy.

The companies deploying agentic payments today are operating in an interpretive gap. The regulations exist. The technology exists. The interpretation connecting the two does not. The first enforcement action involving an agent-initiated payment will set the precedent, and every company in the space will have to adjust based on how that precedent lands.

If you're building agentic payment systems, you should be thinking about four things now: documenting your authorization chain from board delegation to agent policy to individual transaction. Capturing agent reasoning at the time of each payment decision. Deciding how you'll handle the "subject" question on a SAR. And making your compliance records tamper-evident so that an examiner six months from now can trust what they're seeing.

The regulatory clarity will come. It always does. The question is whether you'll have the evidence trail to survive the period before it arrives.

Vinay Narayan is the founder of Legaci Labs. He holds a patent on tamper-evident digest chains for agent audit trails.