ARS-1 defines a portable message protocol for moving value through AI agents — profiled on ISO 20022, FATF Travel Rule-native, addressed via AIS-1 DIDs. The action-protocol complement to AIS-1 (identity) and AAS-1 (audit).
ARS-1 is an open protocol for the agent-mediated movement of value across operators, jurisdictions, and rails. Where AIS-1 outputs a verifiable identity card and AAS-1 outputs signed action records, ARS-1 outputs messages — structured, signed JSON documents that one party hands to another to instruct, execute, confirm, condition, or reverse a value transfer.
The standard addresses what we call the Stranded Agent Problem: agents are now executing value transfer at scale, yet every operator implements its own message format, conditionality grammar, compliance overlay, and addressing scheme. Agents and the value they carry are stranded on whichever rail they were issued on, with no portable protocol for cross-operator settlement and no consistent surface for regulator visibility.
A Class I instruction is simultaneously a valid pain.001 message (routable by any bank running ISO 20022 infrastructure) and a valid ARS-1 instruction (executable by any ARS-1-aware operator). The standard is dual-readable from day one. ISO 20022 conformance rules require <SplmtryData> to be preserved end-to-end without modification, so the agentic payload passes through correspondent-banking infrastructure unchanged.
Conventional remittance addressing is fragmented. Western Union has cash-pickup IDs; mobile-money operators have phone-number-keyed accounts; banks have IBAN/SWIFT/routing pairs; crypto wallets have chain-specific addresses. None is portable. Each provider maintains its own directory of who-to-pay. Each cross-provider integration is bespoke. The result is N² complexity at the network layer.
ARS-1 uses AIS-1 DIDs as the universal addressing scheme. A DID like did:ais1:base:recipient-agent-example is globally resolvable. Any party — anywhere — can resolve it against the public AIS-1 registry and obtain the agent's keys, sponsor, jurisdiction, and AML status.
The analogy. AIS-1 + ARS-1 are to value transfer what DNS + HTTP are to the web. DNS gave every resource on the internet a universal name. HTTP gave every server a shared protocol. Together they killed the era of incompatible online services. AIS-1 gives every agent a universal identifier; ARS-1 gives every operator a shared protocol for transferring value against it. The network effect that follows is structural, not contingent.
A single remittance lifecycle typically begins with a Class I instruction, generates one or more Class T transfers between operators, is governed by zero or more Class C conditionality blocks, and terminates in a Class R receipt. In error, any party may issue a Class V reversal. Every message emits an AAS-1 Class A record at issuance — the audit trail is automatic.
ARS-1 supports three named deployment-pattern profiles. Each is a published reference profile with declared purpose codes, conditionality predicates, onward-delivery channels, and licensing posture. The standard does not endorse or name specific commercial operators; conformance is a matter of meeting the published criteria for the relevant profile.
Profile interoperability. The three profiles share the protocol. A recipient agent provisioned for institutional aid can also receive commercial remittance from a diaspora relative, and welfare from her own government — all to the same AIS-1 recipient agent, all in the same protocol format. The recipient agent is profile-agnostic; the operator is profile-specific. This is the network effect ARS-1 unlocks.
Any operator receiving an ARS-1 Class I message resolves the AIS-1 identities of all named parties, validates the signature, confirms each bond is active, fetches the AAS-1 record, evaluates the compliance block, evaluates the conditionality if present, and routes — or rejects with a typed reason.
// Verifier flow — evaluating an ARS-1 Class I message const msg = await ars1.fetch(messageId); // 1. Resolve AIS-1 identities for all named parties const orig = await ais1.resolve(msg.originatorRef); const origAg = await ais1.resolve(msg.originatorAgentRef); const recipAg = await ais1.resolve(msg.recipientAgentRef); const op = await ais1.resolve(msg.operatorRef); // 2. Validate the message signature against the originator agent's key assert(verifySignature(msg, origAg.verificationMethod)); // 3. Confirm bonds are active for (const id of [origAg, recipAg, op]) { const bond = await ais1.verifyBond(id.bondId); assert(bond.valid && bond.amlStatus === 'cleared'); } // 4. Verify the corresponding AAS-1 record const aasRec = await aas1.fetch(msg.aas1RecordRef); assert(aasRec.agentRef === msg.originatorAgentRef); // 5. Evaluate the compliance block assert(msg.compliance.sanctionsScreening.result === 'clear'); // 6. Evaluate conditionality if present if (msg.conditionality) { const result = await ars1.evaluateConditionality(msg.conditionality); if (!result.satisfied) return reject('conditionality_unsatisfied', result); } // 7. Accept for routing return accept(msg);
Feedback is invited from multilateral institutions and development finance organisations, central banks and supervisory authorities, FATF and AML/CFT regulators, remittance and money-transfer operators, ISO 20022 registration authorities and SWIFT, humanitarian and aid organisations, AI agent developers, legal and compliance professionals, and standards organisations including ISO TC 68, ITU-T, the BIS Innovation Hub, and the FSB. The comment period closes 31 August 2026. A revised draft will be published as v0.3.
We are looking for: review of the ISO 20022 envelope mechanic from registration authorities · feedback on the Class I schema and conditionality grammar · proposed regulatory profile mappings (DABA, MiCA, GENIUS, FATF) · input on selective-disclosure cryptography · proposed supplementary purpose codes through the ISO 20022 RFP process · real-world deployment use cases · support for formal standardisation through ISO TC 68 / SC 8.