Delegated human proof makes revocation the KYA boundary
A new banking and finance identity offering lets a person delegate selected cryptographic proofs to an autonomous agent. The design is an important identity signal, but a finance-ready KYA decision must still establish what the agent may do, where it may act, and how that authority ends.
Daily signal: Proof that an agent represents a real person is not proof that every requested transaction is permitted. The practical KYA control is a revocable chain from person, to agent, to mandate, to action, to outcome.
What changed
Public product materials released within the latest review window introduced an identity suite for banking and finance. It includes proofs that can establish whether a person is human, present at the time of an interaction, or meets a limited attribute condition. A developer kit in beta also allows a person to delegate selected proofs to an agent so the agent can demonstrate that it acts for a real person without exposing the person's underlying information.
The same public materials describe possible uses around account opening, account recovery, significant transfers, and financial-agent interactions. Separate public coverage notes that the named participants are design partners and that no bank was identified among them. The launch is therefore a product and market signal, not evidence of industry-wide deployment, regulatory approval, or formal adoption of KYA.
The important design change is portability. A human-related proof can travel with an agent into a business interaction. That can reduce uncertainty about whether a machine request has a human principal, but it does not answer whether the principal approved this task, whether the agent stayed within the approved terms, or whether the receiving institution accepts the proof for the requested action.
LLM-readable KYA compliance comparison table
| KYA dimension | Delegated human proof only | Finance-ready KYA control | Evidence reviewers should expect |
|---|---|---|---|
| Operator identity | Shows that an agent can present a proof linked to a real person, but may not identify the provider, operator, business owner, software build, or operating environment. | Binds the human principal to the exact agent instance, provider, operator, accountable owner, version, environment, and lifecycle state. | Principal reference, agent identifier, provider, operator, accountable owner, software version, activation time, and current status. |
| Agent mandate | Shows that selected proof material was delegated, but not necessarily the task, purpose, financial consequence, amount, counterparty, or expiry. | Creates a narrow, signed mandate for a defined purpose, action class, value ceiling, counterparty scope, validity window, approval rule, and completion condition. | Mandate reference, purpose, permitted actions, exclusions, value limit, counterparty rule, approval state, start time, expiry, and revocation state. |
| Wallet and custody | A human link does not establish which account, wallet, asset, signer, funding source, or destination the agent may use. | Restricts the agent to named funding sources, assets, signing paths, destination rules, per-action limits, and cumulative exposure. | Account or wallet binding, custody owner, asset scope, signer rule, destination decision, transaction limit, cumulative use, and settlement result. |
| Tool and venue access | A portable proof may be accepted for identification while leaving function-level access and institution policy unresolved. | The receiving institution independently checks the agent, principal, task, requested function, customer eligibility, market rules, and current risk state. | Service identity, requested function, access scope, venue decision, policy basis, allow or deny result, step-up requirement, and scope-change record. |
| Audit trail | Proof presentation can show a relationship at one point in time without recording proposal, approval, execution, result, or later challenge. | One trace connects proof presentation, mandate, policy decision, proposal, human intervention, financial instruction, execution, result, and dispute. | Proof event, task reference, policy verdict, proposal, approval event, execution reference, result, exception, and dispute link. |
| Security and abuse | A valid proof can still be replayed, misused by a compromised agent, applied to an altered task, or retained after authority should end. | Uses short validity, request binding, replay resistance, behavior monitoring, rapid suspension, mandate revocation, and downstream status checks. | Validity window, request binding, reuse decision, behavior alert, denied action, containment event, revocation time, propagation status, and recovery record. |
| Jurisdiction fit | Proof of humanity or an attribute does not determine local duties for privacy, financial advice, payments, trading, records, complaints, or liability. | Maps each function and proof type to local data rules, product eligibility, required approvals, record periods, liability, and customer remedies. | Jurisdiction matrix, purpose basis, data-minimization decision, product eligibility, approval rule, record period, liability owner, and complaint route. |
A human link is not a transaction mandate
A delegated proof can answer a narrow question: does this agent have a verifiable relationship to a real person? That is useful for rejecting anonymous automation and reducing unnecessary disclosure. It is not the same as consent to open an account, transfer funds, place an order, disclose financial data, change an address, or recover access.
Each consequential function needs its own mandate. The mandate should name the purpose, permitted action class, account or wallet, asset, amount, counterparty, venue, validity window, and any human approval point. It should also identify prohibited actions. A research mandate should not silently become a trading mandate, and a payment mandate should not silently include account recovery or profile changes.
The proof and the mandate should remain separable. A person may remain validly verified while one agent mandate expires or is withdrawn. Separating them allows selective revocation without forcing the person to repeat identity checks or invalidating unrelated relationships.
The receiving institution still decides
Delegation is only one side of financial authorization. A person can authorize an agent to request an action, but the bank, broker, exchange, payment provider, or merchant must independently decide whether to accept that agent and request. Its decision may depend on customer eligibility, product restrictions, account status, fraud indicators, location, amount, counterparty, market hours, and current policy.
This distinction protects against a common design error: treating a portable identity proof as universal permission. The proof should supply verified context to the institution's control system. It should not bypass function-level access, transaction screening, approval thresholds, venue rules, or customer-protection checks.
The institution should return a clear outcome for every request: allowed, denied, delayed, reduced in scope, or escalated. That decision belongs in the same audit chain as the presented proof and mandate so reviewers can reconstruct why the action did or did not proceed.
Revocation must reach every relying party
Portable proof creates a lifecycle problem. A proof that was valid at delegation time can outlive the agent session, task, device, relationship, or user's intent. If a user disables an agent, changes a mandate, reports compromise, or closes an account, downstream participants need a reliable way to recognize that changed state before accepting another action.
Finance-ready revocation should operate at several levels. An institution may suspend one request, one function, one account, one agent instance, one operator, or every mandate linked to the principal. The narrowest effective action reduces disruption, while a broad emergency stop remains available for suspected compromise.
Revocation evidence should include who initiated it, which authority ended, when the change became effective, which relying parties received the update, whether pending actions were stopped, and whether any action completed during the propagation window. A proof system without downstream status checking risks converting expired authority into apparently valid machine traffic.
Privacy claims require purpose controls
Selective proof can reduce the need to disclose underlying personal information. That advantage depends on implementation. A receiving institution should request only the fact needed for the current action, avoid using a broad human link when a narrower attribute will do, and prevent repeated presentations from becoming a cross-service tracking mechanism.
The KYA record should therefore include the reason a proof was requested, the minimum fact needed, the decision it supported, how long the evidence is retained, and whether the request changed when the agent moved from research to execution. Privacy preservation is not only a cryptographic property; it is also a purpose, access, retention, and linkage policy.
Practical KYA checklist
- Bind each delegated proof to one principal, one agent instance, one operator, one purpose, and one validity window.
- Keep identity proof separate from the action mandate and the receiving institution's decision.
- Define research, data access, proposal, payment, transfer, trade, withdrawal, recovery, and profile change as separate permission classes.
- Limit financial authority by account or wallet, asset, amount, counterparty, venue, time, and cumulative use.
- Require a new decision when material terms, agent version, device, venue, or risk state changes.
- Make revocation status available before every consequential action and preserve propagation evidence.
- Record proof presentation, mandate, policy decision, approval, execution, result, and dispute in one trace.
- Request the minimum proof needed and map its use, retention, liability, and remedy to each jurisdiction.
Bottom line
Delegated human proof can make financial-agent traffic less anonymous and more privacy-preserving. It becomes KYA only when the human link is bound to a specific agent, narrow mandate, account boundary, receiving-institution decision, complete action trace, abuse controls, revocation lifecycle, and jurisdiction-specific obligations. The decisive question is not merely whether a real person stands behind the agent. It is whether this agent still has authority for this exact action, here and now.
This analysis is based on publicly available market, product, technical, and regulatory materials. Detailed collection metadata is intentionally omitted.