Know Your Agent (KYA): The Legal Compliance Standard for AI Agents That Move Money

By Chanté Eliaszadeh | July 2026

On June 10, 2026, Mastercard launched Agent Pay for Machines --- machine-to-machine payments with on-chain stablecoin settlement and programmatically enforced, credentialed agent permissions --- and Visa announced its OpenAI partnership at the Visa Payments Forum the same week.¹ Know Your Agent (KYA) --- the standard we define in this series --- is what the law asks of everyone building on those rails: before an AI agent moves money, someone must be able to say which legal person answers for it.

The rails are no longer pilots. The liability law has not moved. Every emerging technical standard --- Visa’s, Mastercard’s, Google’s, the identity questions in NIST’s February 2026 concept paper --- builds cryptographic proof of which agent acted, and none of them identifies the accountable legal person behind it.² That gap is not a technology problem. It is the oldest question in commercial law, wearing new infrastructure.

This article defines the Know Your Agent standard as we have developed it across this series: what KYA is, how it differs from the identity tooling sold under the same acronym, who actually bears the loss on each payment rail today, and the five pillars a deployer builds before a regulator --- or a plaintiff --- asks.

Key Takeaways

• KYA is a legal standard. It identifies the accountable legal person behind a transacting agent --- extending KYC’s customer-identification logic under 31 C.F.R. Section 1020.220³ --- while vendor KYA tools verify credentials.⁴
• The consumer liability caps may not protect agent users. TILA’s $50 cap and Regulation E’s tiers apply only to “unauthorized” transactions, and both statutes arguably exclude transfers by an agent the consumer furnished with credentials.⁵⁶
• An AI agent cannot be the BSA customer. The customer must be a legal person; the deployer’s wrapper entity is the customer, and every KYA obligation attaches to it.⁷
• The card networks’ protocols stop at evidence. Visa, Mastercard, and Google AP2 establish cryptographic identity and audit trails; none allocates legal liability or identifies a BSA customer.
• No regulator has filled the gap. As of July 18, 2026, none of the four GENIUS Act stablecoin AML rulemakings names an AI-agent category, and all four remain proposed rules.⁸

What Is Know Your Agent (KYA)?

Know Your Agent (KYA), as this series defines it, is a legal-compliance standard that identifies the accountable legal person behind an autonomous AI agent --- extending KYC’s customer-identification logic to agents that transact --- through five pillars: identity, authority, monitoring, incident response, and compliance readiness.

The acronym is crowded, so precision matters. Identity-verification vendors and technical standards bodies use “KYA” for credential tooling: the AgentFacts standard, for example, publishes its own four-pillar technical KYA framework built on verifiable agent metadata.⁴ Those products answer a real question --- which agent is this? --- with cryptographic rigor. But no credential answers the question the law asks when money moves: which legal person answers for this transaction? KYC never certified account software; it identified the customer. KYA, in the legal sense this article defines, does the same one layer up. It is a compliance program that maps each obligation to law that already exists --- customer identification under 31 C.F.R. Section 1020.220, authorization doctrine under UCC Article 4A, BSA recordkeeping.³

Vendor evaluation solves identity verification. Customer identification, authorization, and liability are the legal layer, and they are still yours.

Who Bears the Loss When an AI Agent Makes an Unauthorized Transfer?

It depends on the rail --- and every rail converges on the customer: the TILA and Regulation E consumer caps may not apply where the consumer furnished the agent its credentials, and UCC Article 4A can shift a business wire loss to the customer.

Start with the caps everyone recites. For consumer credit cards, TILA caps cardholder liability for unauthorized use at $50, and the card issuer bears the burden of proving the use was authorized.⁹ For consumer bank transfers, the EFTA and Regulation E run a three-tier structure: $50 with notice within two business days, up to $500 without it --- and unlimited liability for unauthorized transfers occurring more than 60 days after the periodic statement without notice, which is precisely the pattern a quietly misbehaving recurring agent produces.⁵

Both caps share a predicate problem. TILA’s cap applies only to “unauthorized use,” which the statute defines, as used in section 1643, as “a use of a credit card by a person other than the cardholder who does not have actual, implied, or apparent authority for such use and from which the cardholder receives no benefit.”⁶ An agent the consumer handed the card credentials arguably has actual authority --- which would take the loss outside the cap entirely. Regulation E is more explicit still: an “unauthorized electronic fund transfer” excludes any transfer initiated by a person the consumer furnished with the “card, code, or other means of access,” until the consumer gives notice.¹⁰ Whether those exclusions reach a consumer’s own AI agent is unresolved --- Fenwick & West put it plainly in April 2026: “It is currently unresolved whether a consumer granting an AI agent access to their bank account or payment credentials satisfies Regulation E’s authorization requirements.”¹¹ We map the consumer side of that gap, including whether the consumer caps survive credential-sharing, in our analysis of who is liable when AI agents lose money.

Business wires are harsher. Under UCC Article 4A, a payment order verified through a security procedure that is “a commercially reasonable method of providing security against unauthorized payment orders” is effective as the customer’s order --- authorized or not --- if the bank accepted it in good faith and in compliance with the procedure.¹² The inversion: the agent’s own verified signing credentials are the commercially reasonable security procedure. A business that hands its agent signing keys has pre-authenticated every order the agent sends. Hardening the agent’s signing infrastructure without bounding its attested authority does not reduce exposure; it perfects the bank’s defense.

The consumer caps are routinely cited as if they resolve agent losses. Their shared statutory predicate --- an “unauthorized” use or transfer --- is precisely what a consumer who hands an agent its credentials may have forfeited. Whether the caps survive credential-sharing is unresolved; what is already visible is that all four rows converge on the customer once credentials reach an agent. That convergence is the case for the KYA-AUTH attestation described below: bounded, attested authority is what keeps “the agent had my credentials” from becoming “the agent had my authority.”

Assume the statutory caps are contested territory wherever payment credentials reach an agent --- yours or your customers’ --- and build the authority record that wins the fight either way.

Can an AI Agent Be the BSA Customer?

No. The BSA “customer” must be a person, and an AI agent is not one: it cannot satisfy customer identification as an individual or as an entity. The customer is the identified legal entity that deploys the agent: the wrapper.

The ground for that “no” is definitional. The customer-identification rules define “customer” through the BSA’s definition of “person” --- individuals, corporations, partnerships, trusts, and other recognized legal persons.⁷ An AI agent appears nowhere on that list. The attribute failures merely illustrate the point in each mode: as an individual, an agent has no date of birth or government identification number to collect --- elements CIP requires only “for an individual”; as an entity, it has no formation documents or EIN, because no one formed it as anything.³ Corporations lack birthdays too, and they are CIP customers every day --- the difference is that a corporation is a legal person and an agent is not.

The answer is not to force the agent into the customer’s chair. The answer is two centuries old. Since Dartmouth College v. Woodward in 1819, American law has handled non-human actors through the same device: a legal entity that holds the rights, bears the obligations, and answers in court.¹³ The wrapper is the identified legal entity that deploys an AI agent and to which every KYA obligation attaches. The wrapper --- an LLC, a corporation, an existing operating company --- satisfies CIP with formation documents and an EIN, discloses its beneficial owners under the 25-percent-ownership and significant-responsibility-control tests, and stands behind the agent’s transactions.¹⁴ The GENIUS Act sharpened the stakes in July 2025 by making permitted payment stablecoin issuers financial institutions under the BSA --- so the institutions running agent-native rails will need an answer to “who is your customer?” that examination can survive.¹⁵ The full wrapper analysis --- including who is the BSA customer when an AI agent sends stablecoins --- lives in our stablecoin deep dive; the holding travels everywhere: the agent is never the customer, and never the liable principal.

If your agent holds a wallet and no legal entity is identified behind it, what you have is an unanswerable examination question.

What Are the Five Pillars of Astraea’s KYA Standard?

Astraea’s KYA framework organizes agent compliance into five pillars --- KYA-ID (identity), KYA-AUTH (authority), KYA-MON (monitoring), KYA-IR (incident response), and KYA-COMP (compliance readiness) --- each mapping an existing legal obligation onto the deployer of a transacting AI agent.

The five pillars are our own taxonomy, developed across this article series --- not an industry standard. Other groups publish different pillar sets under the same acronym, and the technical standards named above use different categories entirely. What distinguishes this taxonomy is its anchor: every pillar corresponds to law that already binds the deployer today, which means a KYA program is not preparation for a future rule --- it is the organized satisfaction of present ones.

Produce this table’s right-hand column for your agent today and you have a KYA program. Whatever you cannot produce is your litigation exposure, itemized.

What Is a Deployer Attestation and Why Does It Sit at the Signing Layer?

Within Astraea’s KYA framework, the deployer attestation is the KYA-AUTH pillar’s operative instrument: the wrapper entity’s signed grant of bounded transaction authority to its agent --- limits, allowlists, expiration --- enforced where the agent signs, not in a terms-of-service promise.

The location is the doctrine. Under UCC Article 4A, the bank’s defense is built on the security procedure the parties agreed to --- so the only scope limit the statute respects is one the signing infrastructure actually enforces.¹² An attestation whose transaction cap lives in a policy document does nothing when the agent signs a wire five times its mandate; an attestation enforced at the signing layer means the out-of-scope order never becomes a verified order at all. The same logic runs through apparent authority: a counterparty cannot read a terms-of-service page the agent never showed it, but it can read an enforced, verifiable grant. Our stablecoin analysis carries the attestation’s on-chain mechanics; the flagship point is architectural --- authority must be bounded where it is exercised.

Compare what the payments industry is building instead. Google’s Agent Payments Protocol (AP2), announced September 16, 2025, binds agent transactions to cryptographically signed Intent and Cart Mandates and promises “a non-repudiable audit trail … providing a clear foundation for accountability.”¹⁹ An audit trail identifies what happened. An attestation determines who answers, and within what bounds. And for an unbounded deployment, the inversion is uncomfortable: a non-repudiable trail is non-repudiable evidence against the deployer --- you cannot disclaim the transaction your agent verifiably signed. Evidence infrastructure without authority infrastructure is a liability accelerant.

If your agent’s transaction limits live in a document rather than in its signing path, you have written evidence of the authority you failed to bound.

Do Visa, Mastercard, and Google’s Agent Protocols Answer the Liability Question?

No. Visa’s Trusted Agent Protocol, Mastercard’s Agent Pay, and Google’s AP2 build cryptographic identity, tokens, and audit trails for agent transactions --- but none assigns legal liability or identifies the accountable BSA customer. The legal layer stays with the deployer.

The build-out has been fast and real. Visa announced Intelligent Commerce in April 2025 with AI-model partners including OpenAI, and describes the product as in deployment rather than general availability.²⁰ Visa’s separate Trusted Agent Protocol followed on October 14, 2025, an ecosystem framework for agent-merchant trust built on HTTP Message Signatures with Cloudflare and payment partners.²¹ Mastercard launched Agent Pay in April 2025, binding agent transactions to tokenized credentials.²² And on June 10, 2026, Mastercard’s Agent Pay for Machines (AP4M) went furthest: machine-to-machine payments with on-chain stablecoin settlement and programmatically enforced, human-granted agent permissions (authorization rules and spending limits).¹

AP4M is the closest technical analog to KYA-AUTH yet shipped --- an enforceable credential and permission layer, not just an audit trail --- and it deserves honest engagement. It partially answers the accountability gap --- the permission is real and enforced. What remains open is everything the enforcement cannot reach: who granted the permission, with what legal authority, answerable to whom. An enforceable permission is not an accountable legal person. That residue --- the BSA customer, the statutory liability allocation, the wrapper and its attestation --- is the KYA claim, stated precisely.

Every row is the same sentence with different engineering: the industry is building proof of which agent acted, while the law keeps asking which person answers. The first question is now largely solved. The second is the one that decides lawsuits, examinations, and enforcement --- and it is the one KYA exists to answer.

A deployer whose compliance narrative consists of a protocol integration has adopted evidence standards for a liability question no protocol decides.

What Has Actually Gone Wrong With Transacting AI Agents?

Thinner than the headlines suggest --- and the best-documented case was a designed demonstration: in November 2024 the Freysa prize-game agent, instructed never to transfer its roughly $45,000 pool, was talked into transferring it. Verified operational losses remain scarce; the exposure is not.

Freysa deserves precision, because it is usually miscited. It was an adversarial game, launched November 22, 2024: an agent held a prize pool under an explicit instruction never to transfer it, and paying participants submitted messages trying to argue it into doing so. After 195 participants and 482 messages, a winning prompt landed days later, in late November 2024 --- it redefined the agent’s transfer-approval function so that releasing the pool looked like following instructions, and the agent sent roughly $45,000 to the winner.²³ The payout was the game’s intended win condition, not an in-the-wild operational loss. But the mechanism is the lesson: the agent was never impersonated and its keys were never stolen. Its instructions were rewritten in flight, and it followed them. That is a KYA-AUTH failure --- unbounded authority --- and no credential standard in the preceding section would have prevented it.

The candid finding is the scarcity itself. Reliable, verifiable loss data on autonomous-agent transactions barely exists; the flagship exhibit is a controlled experiment. That is not comfort. It means the statutes mapped above will be tested by the first well-lawyered dispute, not by aggregate loss statistics --- and the deployer in that dispute will be the one whose authority records are examined line by line.

Freysa’s attackers never stole a key. Build the incident-response plan for the failure mode they actually used: instructions rewritten in flight.

Where Do Regulators Stand on AI-Agent Transactions?

Nowhere definitive. FinCEN’s April 2026 stablecoin rulemaking names no AI-agent category, NIST’s February 2026 concept paper poses identity questions it does not answer, and no U.S. regulator has allocated liability for autonomous-agent transactions.

The FinCEN finding is a positive one, not an assumption. The joint FinCEN and OFAC proposed rule for permitted payment stablecoin issuers --- published April 10, 2026, at 91 Fed. Reg. 18582, implementing the GENIUS Act, with comments closed June 9, 2026 --- contains zero occurrences of “AI agent,” “autonomous agent,” “automated agent,” or “machine learning.”²⁴ “Artificial intelligence” appears exactly twice, both times as an example of an issuer’s transaction-monitoring tools. The only AI FinCEN contemplates is the kind that watches transactions, not the kind that makes them. And the vacuum is wider than one rule: as of July 18, 2026, every GENIUS Act stablecoin AML rulemaking in the Federal Register --- four proposed rules published between April 10 and June 24, 2026, covering AML/CFT programs, customer identification, and sanctions risk management --- remains proposed, none final, and none names an AI-agent category.⁸ NIST’s National Cybersecurity Center of Excellence closed comments on its agent identity and authorization concept paper on April 2, 2026, with its governance questions --- identification, authorization, delegation, logging --- still posed, not answered.²

The EU is the one jurisdiction with a dated obligation on the calendar, and it needs stating precisely. Under the EU AI Act, the remaining tranche of obligations --- including the high-risk regime --- nominally applies from August 2, 2026.²⁵ No Annex III category squarely covers a payment or purchasing agent, so there is no blanket high-risk classification for transacting agents; the obligations that clearly do reach consumer-facing agents are Article 50’s transparency duties for AI systems that interact with natural persons --- the consumer must know it is dealing with an agent --- and the general-purpose-model obligations on the models the agents run on. The one predicate-named high-risk example: an agent that itself evaluates the creditworthiness of natural persons falls under Annex III point 5(b), which expressly excepts fraud-detection AI. The August 2 date itself is in flux: a proposed Digital Omnibus package would postpone stand-alone Annex III obligations to December 2, 2027, but it was not enacted as of July 18, 2026, so August 2, 2026 remains the operative statutory date. Whichever date holds, the analytical point survives: the EU obligations --- transparency, documentation, oversight, post-market monitoring --- map directly onto KYA-COMP and KYA-MON. The deployer who builds the KYA file is building the EU compliance file.

If you are waiting for a regulator to tell you what an agent deployment requires, understand what the record shows: the rules now in progress do not mention you. The obligations that already bind you were written decades ago, and they are the ones in the tables above.

How Should a Deployer Implement KYA Before Regulators Require It?

Start with the wrapper: form or designate the legal entity that owns the agent’s credentials, then build the five pillars in order --- identity, attested authority, transaction monitoring, incident response, and examination-ready records.

The sequence, keyed to the pillar each step builds:

• Choose the rail first, then the entity (KYA-ID). Card, ACH, wire, or stablecoin decides which liability regime the deployment lives under --- and whether the operation needs a money transmitter license before anything else.
• Form or designate the wrapper and complete its identification file (KYA-ID). Formation documents, beneficial owners, and a registry binding each agent credential to the entity.
• Write the deployer attestation and enforce it at the signing layer (KYA-AUTH). Transaction limits, counterparty allowlists, expiration --- enforced in the signing path itself.
• Stand up scope-deviation monitoring before the first production transaction (KYA-MON). Logs tied to the attestation, alerts on out-of-scope attempts.
• Test the kill switch and the notification matrix before an incident (KYA-IR). The first hour after an agent exceeds scope should run on a rehearsed procedure.
• Assemble the examination-ready KYA file (KYA-COMP). Attestations, logs, incident records, refresh dates --- the file that answers a regulator, and the exhibit set that answers a plaintiff invoking the seven doctrines that already hold AI deployers liable.

The first-mover advantage here is evidentiary. When the first serious agent-loss dispute arrives, the deployer with a KYA file answers a subpoena in days. The deployer without one answers with discovery --- every log, every design decision, every unbounded permission, extracted adversarially, motion by motion. The obligations are already law. The only open question is whether you organize the proof before someone else demands it.

Related Resources

• Who Is the BSA Customer When an AI Agent Sends Stablecoins?
• Who Is Liable When an AI Agent Loses Your Money?
• Does Your Agentic-Payments Startup Need a Money Transmitter License?
• Not an Agent. Not a Defense: Seven Doctrines That Already Hold AI Deployers Liable

Attorney Advertising. This article provides general information for educational purposes only and does not constitute legal advice. AI and financial-services regulation is evolving rapidly. Consult qualified legal counsel for advice on your specific situation.

Footnotes

1. Mastercard, “Mastercard launches Agent Pay for Machines to unlock super-fast, always-on payments” (June 10, 2026), available at https://www.mastercard.com/us/en/news-and-trends/press/2026/june/mastercard-launches-agent-pay-for-machines.html; on the Visa-OpenAI announcement, Digital Commerce 360, “Visa, OpenAI partner on agent-led payments” (June 12, 2026), available at https://www.digitalcommerce360.com/2026/06/12/visa-openai-agent-led-payments/. ↩ ↩²

2. National Institute of Standards and Technology, National Cybersecurity Center of Excellence, “Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization” (concept paper, Feb. 5, 2026; comments closed Apr. 2, 2026), available at https://csrc.nist.gov/pubs/other/2026/02/05/accelerating-the-adoption-of-software-and-ai-agent/ipd. ↩ ↩² ↩³

3. 31 C.F.R. Section 1020.220 (customer identification programs for banks), available at https://www.ecfr.gov/current/title-31/subtitle-B/chapter-X/part-1020/section-1020.220. ↩ ↩² ↩³

4. AgentFacts, “Know Your Agent (KYA),” available at https://agentfacts.org/kya/. ↩ ↩²

5. 15 U.S.C. Section 1693g (Electronic Fund Transfer Act, consumer liability); 12 C.F.R. Section 1005.6(b)(1)-(3) (Regulation E, liability of consumer for unauthorized transfers), available at https://www.law.cornell.edu/cfr/text/12/1005.6. ↩ ↩²

6. 15 U.S.C. Section 1602(p) (Truth in Lending Act, definition of unauthorized use), available at https://www.law.cornell.edu/uscode/text/15/1602. ↩ ↩²

7. 31 C.F.R. Section 1020.100(b) (definition of customer), available at https://www.ecfr.gov/current/title-31/subtitle-B/chapter-X/part-1020/section-1020.100; 31 C.F.R. Section 1010.100(mm) (definition of person), available at https://www.ecfr.gov/current/title-31/subtitle-B/chapter-X/part-1010/section-1010.100. ↩ ↩²

8. Astraea Counsel analysis of Federal Register rulemaking data as of July 18, 2026: search of GENIUS Act stablecoin AML/CFT actions via the Federal Register API returned four proposed rules and no final rule --- “Permitted Payment Stablecoin Issuer Anti-Money Laundering/Countering the Financing of Terrorism Program and Sanctions Compliance Program Requirements,” 91 Fed. Reg. 18,582 (Apr. 10, 2026); “Bank Secrecy Act and Sanctions Compliance Standards for FDIC-Supervised Permitted Payment Stablecoin Issuers,” 91 Fed. Reg. 34,171 (June 5, 2026); “Permitted Payment Stablecoin Issuer Customer Identification Program” (June 22, 2026); “Permitted Payment Stablecoin Issuer Anti-Money Laundering/Countering the Financing of Terrorism and Sanctions Compliance Risk Management” (June 24, 2026). Source: https://www.federalregister.gov. ↩ ↩²

9. 15 U.S.C. Section 1643(a)(1), (b) (Truth in Lending Act, liability of holder of credit card), available at https://www.law.cornell.edu/uscode/text/15/1643. ↩

10. 15 U.S.C. Section 1693a(12) (Electronic Fund Transfer Act, definition of unauthorized electronic fund transfer; the quoted “card, code, or other means of access” language is the statute’s); 12 C.F.R. Section 1005.2(m) (Regulation E parallel definition, phrased through the “access device” term defined at 12 C.F.R. Section 1005.2(a)(1)), available at https://www.ecfr.gov/current/title-12/chapter-X/part-1005/section-1005.2. ↩

11. Fenwick & West LLP, “Is 2026 the Year of Agentic Payments?” (Apr. 22, 2026), available at https://www.fenwick.com/insights/publications/is-2026-the-year-of-agentic-payments. ↩

12. UCC Section 4A-202(b); Section 4A-203 (uniform text), available at https://www.law.cornell.edu/ucc/4A/4A-202. The UCC applies as enacted by each state; cite the governing jurisdiction’s codification for any specific deployment. ↩ ↩²

13. Trustees of Dartmouth College v. Woodward, 17 U.S. (4 Wheat.) 518 (1819), available at https://www.law.cornell.edu/supremecourt/text/17/518. ↩

14. 31 C.F.R. Section 1010.230 (beneficial ownership requirements for legal entity customers), available at https://www.ecfr.gov/current/title-31/subtitle-B/chapter-X/part-1010/section-1010.230. ↩

15. GENIUS Act, Pub. L. No. 119-27, Section 4(a)(5)(A) (July 18, 2025; 139 Stat. 419; codified at 12 U.S.C. Sections 5901-5916), available at https://www.congress.gov/bill/119th-congress/senate-bill/1582. ↩

16. 31 C.F.R. Section 1020.320 (reports by banks of suspicious transactions), available at https://www.ecfr.gov/current/title-31/subtitle-B/chapter-X/part-1020/section-1020.320. ↩

17. 12 C.F.R. Section 1005.11 (Regulation E, procedures for resolving errors), available at https://www.ecfr.gov/current/title-12/chapter-X/part-1005/section-1005.11. ↩

18. 31 C.F.R. Section 1010.410 (records to be made and retained by financial institutions), available at https://www.ecfr.gov/current/title-31/subtitle-B/chapter-X/part-1010/section-1010.410. ↩

19. Google Cloud, “Announcing Agent Payments Protocol (AP2)” (Sept. 16, 2025), available at https://cloud.google.com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol. ↩

20. Visa, “Visa Intelligent Commerce” (announced Apr. 30, 2025), available at https://www.visa.com/en-us/solutions/intelligent-commerce (product described as in deployment, not general availability). ↩

21. Visa, “Visa Introduces Trusted Agent Protocol: An Ecosystem-Led Framework for AI Commerce” (Oct. 14, 2025), available at https://investor.visa.com/news/news-details/2025/Visa-Introduces-Trusted-Agent-Protocol-An-Ecosystem-Led-Framework-for-AI-Commerce/default.aspx. ↩

22. Mastercard, “Mastercard unveils Agent Pay, pioneering agentic payments technology to power commerce in the age of AI” (Apr. 29, 2025), available at https://www.mastercard.com/us/en/news-and-trends/press/2025/april/mastercard-unveils-agent-pay-pioneering-agentic-payments-technology-to-power-commerce-in-the-age-of-ai.html. ↩

23. Simon Willison, “0xfreysa/agent” (Nov. 29, 2024), available at https://simonwillison.net/2024/Nov/29/0xfreysaagent/ (describing the Freysa AI agent prize game: launched Nov. 22, 2024; approximately $45,000 pool; 195 participants; 482 messages). ↩

24. Financial Crimes Enforcement Network and Office of Foreign Assets Control, Permitted Payment Stablecoin Issuer Anti-Money Laundering/Countering the Financing of Terrorism Program and Sanctions Compliance Program Requirements (proposed rule), 91 Fed. Reg. 18582 (Apr. 10, 2026) (docket FINCEN-2026-0100; comment period closed June 9, 2026), available at https://www.federalregister.gov/documents/2026/04/10/2026-06963/permitted-payment-stablecoin-issuer-anti-money-launderingcountering-the-financing-of-terrorism. ↩

25. Regulation (EU) 2024/1689 (EU AI Act), arts. 50, 113, Annex III point 5(b), available at https://eur-lex.europa.eu/eli/reg/2024/1689/oj. ↩