Analysis · reviewed 1 October 2026

AFSPAgentic Financial Services Protocol

Sponsor
Primitive, as founding author and interim administrator; governance to pass to an AFSP Foundation targeted for early 2027
Status
v0.1 Public Review Draft; public comment open until 16 November 2026
First published
28 September 2026
Layers
IdentityAuthorityGovernance

AFSP standardises admission: whether this agent, for this person, in this session, may proceed. Most of the protocol answers that question; scope and per-transaction checks are present but tied to the session.

What it is

AFSP is a draft industry protocol for one moment: an AI agent arriving at a regulated financial institution on behalf of a person. Before the agent reaches the institution's systems, the institution verifies who the agent is, who it is acting for, and that the person is present and in control. The specification puts its own scope in one sentence: AFSP governs whether an AI agent session should proceed to the open banking API layer.

Version 0.1 specifies six of twelve components, AFSP-01 to AFSP-06, in enough detail to run one use case end to end: agent-assisted opening of a new deposit account. The agent assembles a Pre-Credential Agent Attestation (PCAA) package carrying up to five trust signals and sends it to the institution the consumer chose. The institution returns a signed clearance decision. On PROCEED_TO_KYC the AFSP platform mints a single-use session token, and the institution then runs its own KYC directly with the consumer. The platform takes no part in KYC or the account decision.

Trust signalsS1 agent provenance (mandatory), S2 biometric consent (mandatory), S3 federated referral (optional), S4 financial identity (mandatory), S5 session integrity (conditional)
Clearance decisionsPROCEED_TO_KYC, REQUEST_ADDITIONAL_VERIFICATION, DECLINE_SESSION
Session tokenMinted only on PROCEED_TO_KYC; single use; valid for at most 1,800 seconds
SignaturesECDSA-P256, over canonical JSON; consumer authorisation signed by a key held in the device's trusted execution environment
Action classesREAD, DISCOVER, PRESENT, INITIATE, EXECUTE
Not yet specifiedProtocol binding (transport, endpoints, message formats), reference implementation, conformance tests
LicensingSpecification under FRAND terms; provisional patent applications filed on the underlying mechanisms

What it actually standardises

Mostly the evidence an institution needs before deciding to deal with an agent at all. That covers a certified, unmodified agent build; a biometric consent event on an enrolled device; an attestation of the consumer's financial profile that discloses no identity; and behavioural signals that the session is being operated by a human. Each signal is signed by its source and assembled into one package bound to one institution, with a nonce and a short validity window against replay.

It also defines how far the agent may go once admitted. Section 7.4 sets out a three-layer Authorization Scope Envelope. The outer layer is the credential's tier. The middle layer is the consumer-defined scope set at session start: institutions, product categories, action classes and amount parameters. The inner layer is an Intent Verification Checkpoint that pins the exact payee, amount, account and timing of an INITIATE or EXECUTE action before it is signed. Initial funding transfers for the new account fall under EXECUTE.

What it assumes about the human

That the person is present. Biometric consent is a mandatory signal, step-up confirmation is required for higher action classes, and the Intent Verification Checkpoint shows the person the specific action before it is signed. The model is built for a supervised session that ends in a decision, not for authority left running after the person has gone.

Scope is set at the start of the session and lives in that session's tokens. Changing it means reconfirming biometrically. That suits account opening. Standing authority, such as a monthly budget across many sessions or a rule about counterparty history, sits outside the session model by design.

Where it is heading

The v1.0 roadmap adds six components, AFSP-07 to AFSP-12. Three of them move beyond admission. AFSP-09 intercepts every agent-initiated execution for synchronous revalidation against scope, velocity, behavioural envelope and revocation, and is described as reinforcing downstream payment protocols rather than replacing them. AFSP-10 computes a per-credential behavioural baseline at every transaction and routes anomalies to a human. AFSP-11 is a hash-chained, append-only log of every revalidation request, response and execution outcome, with seven-year retention.

The specification says provisional patent applications covering AFSP-07 to AFSP-11 were filed in May 2026, and further applications, including AFSP-12, in September 2026. Essential claims are to be licensed on FRAND terms. Extensions can be proposed through the project's GitHub repository, as minor (optional fields, new enumerated values), major (new components or signals) or profile extensions.

What it does not do

  • One use case in v0.1: agent-assisted opening of a deposit account. Payments, servicing and other products are roadmap.
  • No protocol binding yet. Transport, endpoints and message formats are deferred, so no two implementations can interoperate on v0.1 alone.
  • Scope lives in per-session, per-institution tokens. Authority that persists across sessions, institutions or protocols is outside the model.
  • The components that reach execution (pre-execution revalidation, moment-level behaviour, the lifecycle audit log) are roadmap, not specification.
  • Governance is transitional: Primitive administers the standard until a foundation is formed, and holds the patent filings.

Where mnd8t sits relative to it

Complementary at the boundary, overlapping on the roadmap. AFSP decides whether an agent's session may reach an institution. mnd8t decides whether a particular action is within a persistent, versioned mandate, given what has already been spent under it. An AFSP session token can be an input to an mnd8t decision: mnd8t records it beside the mandate in the Authority Record and can require one, but a valid token adds no authority the mandate does not grant. AFSP-09 and AFSP-11 cover ground near mnd8t's enforcement and evidence. The difference is where authority is held: in one protocol's session tokens, or in a mandate evaluated the same way across protocols and rails. mnd8t is proposing an extension that would let an AFSP session carry that decision; it is drawn below.

mnd8t's proposed extension · not part of AFSP
The approval rides in the intent package, and every AFSP check still runs
  1. Consumer device → AgentSigns a reference to one mandate version in the device's TEE
  2. Agent → Authority providerProposes the specific action
  3. Authority provider → AgentSigned APPROVE, bound to the session and the action
  4. Agent → Consumer deviceConfirmation checkpoint shows the delegation
  5. Agent → InstitutionServicing Intent Package, with the signed approval attached
  6. InstitutionChecks the signature, session and action, then runs every AFSP control as before
mnd8t is preparing this as an extension proposal during AFSP's public comment period, which runs to 16 November 2026. It adds two optional fields to AFSP v0.1 and makes nothing mandatory. The authority provider is asked before the confirmation checkpoint (§5.8) and never sits between the agent and the institution, which verifies the approval against the provider's published keys. A valid approval adds no permission AFSP does not already give: it can only give an institution one more reason to proceed or to decline.
Sources

Last reviewed 1 October 2026. Corrections: hello@mnd8t.com.