Agent identity verification before any payment fires. KYA-first architecture from Catena Labs — ACK-ID attestation, ACK Rulebook capability envelopes, ACKReceipt audit trail. Settles USDC on Base.
"A machine principal's authenticated session — identity is a cryptographic credential bound to the operator, not a human login. The equivalent of a trader's authenticated authorization in a bilateral institutional payment."
The agent holds a wallet on Base with a Catena Labs ACK-ID attestation — a W3C Verifiable Credential linking the agent's DID (typically did:web:catena.inc with an `ACKIdentityService` endpoint, or did:pkh for self-issued agents) to its operating principal. The attestation is the canonical KYA primitive on the agentic rail.
The ACK-ID credential carries the five fields Sean Neville foregrounds in the Catena / a16z framing: principal (who the agent represents), permissions (what the agent may do), constraints (per-transaction and temporal bounds), liability (which entity's BSA program attaches), and reputation (prior compliance behavior). Builder: resolve the agent's DID via the ACK-ID resolver SDK; the credential is retrieved, signature-verified against the issuer's public key, and the principal graph is cached for downstream delegation checks.
Compliance officer: KYA checkpoint KYA-1 (Identity) fires here — before any ACK-Pay session opens, the agent's principal must be identifiable, attestable, and revocation-checked. GENIUS §6 AML/BSA obligations attach to the resolved principal; the agent operating under that principal inherits the principal's BSA program and CIP coverage.
"The trade-counterparty onboarding check in a bilateral institutional payment — both sides prove identity, and both are screened before any obligation is booked."
The agent initiates an ACK-Pay session against the counterparty's endpoint. The counterparty's ACK-ID is resolved and the two DID documents are cross-verified — both parties must present valid, non-revoked credentials. OFAC sanctions screening fires against both wallet addresses via the Chainalysis oracle at 0x40C5...8fb on Base.
If the transfer exceeds $3,000 (US) or €1,000 (EU), Travel Rule data is packaged in IVMS101 format alongside the ACK-ID attestations — the ACK framework treats Travel Rule as a first-class payload field, not an out-of-band message. Builder: `ackPay.openSession({ counterpartyDid, amount })` returns a `SessionContext` with both attestations, the OFAC check result, and (if applicable) the IVMS101 bundle; the SDK halts the session if any gate fails and surfaces a structured error naming the failing check.
Compliance officer: satisfies GENIUS §6 (AML/BSA attribution via dual ACK-ID resolution), §7 (Travel Rule for qualifying amounts), and §8 (foreign-issuer screening if the counterparty agent operates from a non-US jurisdiction — ACK-ID jurisdiction metadata drives this check).
"The corporate authorization matrix check plus the card-scheme MCC allow-list — may this agent commit this principal's funds, for this category, at this amount, right now?"
Before settlement fires, the ACK Rulebook evaluates the agent's delegation chain against its capability envelope — this is where Neville's 'permissions' and 'constraints' from Step 1 become code-enforced policy. The Rulebook is an on-chain (or verifiable off-chain) policy object encoding per-transaction limits, daily caps, permitted merchant categories (as MCCs or ACK category hashes), temporal bounds, and delegation-depth limits.
The delegation chain itself is walked from the agent upward — each hop must have a valid ACK-ID attestation, unexpired delegation, and non-attenuated scope relative to the parent (a child delegation cannot expand a parent's constraints). Builder: `rulebook.evaluate({ agent, target, amount, category, timestamp })` returns `{ allowed: bool, violations: string[] }` — the ACK-Pay session halts with a structured error naming each violated constraint.
Compliance officer: this is the code-enforced KYA-2 (Authorization) checkpoint — the Rulebook evaluates the delegation chain and the capability envelope as a single atomic policy decision. C5 Licensing attaches where the agent operates on behalf of a licensed entity; the Rulebook encodes the licensee's permitted product scope and geographic restrictions. C16 Programmable Compliance is entirely satisfied here — the Rulebook is the canonical artifact of machine-enforced policy in the ACK architecture.
"The execution leg of a correspondent-bank payment — terms agreed, screening passed, now value moves atomically with the negotiated conditions encoded in the settlement instruction."
The agent signs an ACK-Pay Verifiable Payment instruction — a typed-data object containing the session ID, counterparty ACK-ID, amount, asset (USDC), and a hash of the Step 3 Rulebook evaluation. The settlement contract on Base verifies the signature, checks that the Rulebook evaluation hash matches the current Rulebook state (to prevent replay against a stale Rulebook), and executes the USDC transfer via EIP-3009 `transferWithAuthorization`. The full stack below the enforcement line (L1 Network, L2 Consensus, L3 Execution) processes the transfer in a single Base block (~2s).
Builder: `ackPay.settle(sessionId, signedInstruction)` relays the instruction to the ACK-Pay settlement contract; the contract emits `PaymentSettled(sessionId, agent, counterparty, amount, rulebookHash)`, which downstream audit tooling indexes.
Compliance officer: GENIUS §4 reserve-backing obligations apply to the USDC in transit — Circle must maintain 1:1 reserves in USD or short-term Treasuries. Recordkeeping (C11) anchors to the block transaction hash, which is cryptographically linked back to Step 3's Rulebook evaluation and Step 2's ACK-ID session context. The Verifiable Payment model produces a cleaner audit trail than raw ERC-20 transfers because every settlement carries its compliance context as on-chain calldata — an examiner can reconstruct the full decision tree from a single block transaction.
"The signed bilateral confirmation in a correspondent-bank payment — both sides acknowledge settlement and the compliance record crystallizes into the transaction's permanent account history."
The ACK-Pay session closes with a bilateral signed receipt: a W3C Verifiable Credential of type `ACKReceipt` binding the agent's DID, the counterparty's DID, the settled amount, the Base transaction hash, and the Step 3 Rulebook evaluation hash. Both parties sign the receipt — it is independently verifiable by any third party without access to Catena Labs infrastructure.
The agent's reputation (credential-health) score updates: a successful, in-envelope settlement increments the agent's reputation, while any mid-session fault (failed Rulebook eval, OFAC hit, stale delegation, counterparty dispute) decrements it. Builder: the receipt is returned in the session-close callback; persist the VC alongside the transaction hash in durable storage for audit, and feed credential-health deltas back to the ACK-ID issuer for reputation rollup.
Compliance officer: satisfies KYA-5 (Audit) — C11 (recordkeeping under GENIUS §6 and §4(c)) and C12 (independent audit trail for monthly attestation under §4(b)) — and contributes to the agent's credential-health/reputation feed for future reputation-based gating. The receipt is the artifact that rolls up into the principal's monthly reserve attestation.
Resolved 5 steps across 1 chain(s). 0 threshold(s) triggered. Frameworks: Common Reporting Standard / FATCA.
Coverage notes: 5 disclosed gap(s).
Step 1 KYA-1 primitive: resolve did:web:catena.inc with its ACKIdentityService and ACKPaymentService endpoints alongside did:pkh, did:key, did:ion, did:hedera, and did:ethr — benchmarking the ACK-ID identity substrate.
Step 3 KYA-2 tool: interactive tree navigator for multi-level Catena Labs ACK-ID delegation chains with permission attenuation — trace the principal → agent trust path that GENIUS §6 requires for BSA attribution.
Step 3 KYA-3 tool: evaluate an ACK Rulebook against a proposed payment — per-transaction limits, daily caps, permitted MCCs, temporal bounds, and delegation depth. The canonical C16 Programmable Compliance artifact.
End-to-end KYA-4 compliance pipeline with preset agent DIDs, real-time audit record generation, and verifiable credential export — rolling up the ACK-ID, Rulebook, and OFAC decisions into a single examinable trail.
Step 5 verification of the `ACKReceipt` VC issued at session close: signature check, issuer validation, revocation check, claims evaluation. Independently verifiable without access to Catena Labs infrastructure.
{"@context": ["https://www.w3.org/2018/credentials/v1"],"type": ["VerifiableCredential","ACKReceipt"],"issuer": "did:web:receipts.acme-psp.com","issuanceDate": "2026-04-01T14:32:18Z","credentialSubject": {"payer": "did:web:agent.acme-corp.com","payee": "did:web:vendor.eu-payments.fr","amount": "3500.00","currency": "USDC","settlementNetwork": "Base","requestToken": "req_7f3a8b2c"},"proof": {"type": "Ed25519Signature2020","verificationMethod": "did:web:receipts.acme-psp.com#key-1","signatureValue": "eyJhbGciOiJFZERTQSIsImtpZCI6ImRpZDp3ZWI6cmVjZWlwdHMuYWNtZS1wc3AuY29tI2tleS0xIn0"}};