AI agent transaction risk scoring

How scoring runs on a single attempt

At issuance time, the pipeline materialises a risk feature vector bound to a single authorization attempt. Each feature is either present in the proof bundle (cryptographically bound) or supplied by an external validator under a contract that does not require PII egress to the merchant.

In practice, teams implement the vector as a structured record: some fields come straight from the signed bundle, others from counters or eligibility APIs that return yes/no without exporting underlying attributes. The important part is that every field has a declared source—otherwise the score becomes a black box the moment something misfires in production.

1. Intent binding — Merchant category, amount, currency, and endpoint are hashed into the attempt fingerprint.
2. Delegation proof — Delegated permissions and consent proof are verified independently of who “clicked.”
3. Velocity and cohort — Rolling counters apply to the instrument and agent identity handle, not to stored behavioural profiles of the human.
4. Policy intersection — Issuer rules and user caps reduce to a single pass/fail gate before network authorisation.
5. Score → decision — The issuer emits approve, decline, or step-up; the proof object records which rule class fired.

Where current systems fail

Traditional card risk assumes a human session and device graph behind every payment. Agentic commerce breaks that assumption: the authorised actor is non-human, latency budgets are tight, and “behavioural biometrics” are often irrelevant or invasive.

• Issuer — Models trained on card-not-present fraud under-weight delegated scope and over-weight IP/device churn that agents legitimately exhibit.
• Merchant / API — Checkout stacks score “bot likelihood” instead of permission validity, producing false declines on valid delegated flows.
• Offline terminal — Without a bound proof object, terminals fall back to static credentials—replay risk rises when connectivity returns.
• Edge device — Local ML models drift; if scoring is not anchored to issuer keys and nonces, decisions are not reproducible in disputes.

None of this argues against good device intelligence where it helps. The point is narrower: when the actor is delegated software, features that proxy for “human-ness” stop being reliable inputs unless you redefine them around proofs and policy.

Risks and attack surfaces

• Feature poisoning — If any feature channel can be influenced without cryptographic binding, the score is gameable.
• Replay via stale proofs — Risk engines that ignore nonce/freshness windows collapse to “once seen, always valid.”
• Threshold oracle attacks — Adversaries probe declines to map limits; binary eligibility with bounded leakage mitigates this compared to rich score APIs.

How verification or authorization is enforced

Authorization enforcement is the conjunction of: (1) valid signatures on consent and delegation artifacts, (2) policy evaluation on the attempt fingerprint, and (3) issuer network acceptance. Risk scoring does not replace that conjunction—it ranks attempts that already pass structural validity.

Where stateless verification applies

Stateless verification keeps the scoring substrate auditable: each decision references verifier keys, rule versions, and proof identifiers. No central store of “user behaviour” is required to reproduce why an attempt failed.

How AffixIO approaches this

AffixIO treats risk as something that must compose with proofs, not replace them. The goal is not to ship a score to every merchant endpoint; it is to keep issuer decisions legible—binary gates where appropriate, explicit rule references, and verification that does not depend on building a behavioural warehouse on cardholders.

In practice that means: eligibility-style answers where the question is well-scoped, external checks that do not sprawl PII across parties, and room for offline-bounded operation when the network is not guaranteed. None of that removes issuer responsibility; it keeps the evidence chain short enough to audit.

• Binary decisioning at the edge of disclosure — What the merchant needs is usually pass, fail, or step-up—not a full risk histogram.
• No dossier requirement — Proofs and policy versions carry what repeatability needs; long-term profiles are a policy choice, not a technical prerequisite.
• Controlled external validation — Signals enter through contracts that state what leaves the user’s sphere and what does not.
• Operational honesty — Freshness windows and nonce semantics are part of the design, not an afterthought when replay appears in production.

Where this fits in agentic commerce

What this system does not solve

Risk scoring cannot prove user intent if consent artifacts are forged at the source. It does not replace law enforcement or merchant category controls. It cannot eliminate collusion between a compromised user device and a malicious agent operator—only bound blast radius through velocity and policy.

Further reading

• Agentic payments reference architecture
• Authorization model for agent transactions
• Trust infrastructure and nonce stores
• Verified AI agent payments overview
• Policy engines for AI agent payments
• Audit trails for AI agent decisions
• Technical architecture docs