Job · Rung 2 · Rung 3

Stop card testing by agents

Slow down automated card testing at checkout without declining real customers.

For Fraud and trust lead, CISO and head of security. Works at Rung 2 · Operational, Rung 3 · Investigative.

The situation

Business

A merchant, marketplace or ticketing site that takes cards.

Use case

Automated tools try stolen card numbers in small amounts at checkout.

Risk

Chargebacks, processor fines and a blocked merchant account.

Today's failure

Blanket blocks and CAPTCHAs decline real customers and say nothing about why.

Silvector

A deterministic decision per checkout request, with step_up for the uncertain middle and a signed receipt for each call.

Evidence

Receipts that name the rule, chained per tenant stream, that you can hand to a processor.

Judged on

Fraud loss in basis points and the false-decline rate, measured on your own traffic.

Steps

1. See what the policy does with a checkout request

   Send the shape of the request to the public check endpoint. It returns the outcome, the rule and a signed receipt. Nothing about the card is sent or needed.

   shCopy

   curl -s https://api.silvector.com/v1/check \
     -H 'content-type: application/json' \
     -d '{"method":"POST","path":"/checkout"}'

2. Run new rules in shadow mode first

   Shadow mode computes what a new rule would have done next to what the current one did, and the receipt records both as applied_outcome and computed_outcome. For velocity rules it runs under exp.velocity_shadow. Read a day of shadow outcomes before you enforce anything.

3. Prefer step_up to deny in the middle

   When the evidence is mixed, step_up (amber) asks for more, such as a fresh factor, instead of declining. Deny (red) is for requests that fail a verified check, such as a spoofed agent identity. Unknown is never red.

4. Keep the receipts

   Each receipt names the policy bundle hash and the rule. When a dispute comes, the receipt shows which rule fired and that the record was not edited afterward.

Guardrails

• A rate or velocity signal alone is a rung 1 signal. Do not present it as a finding that a person is a fraudster.
• Shared networks (offices, universities, mobile carriers) look like bursts. Step up; do not deny on network alone.

What works today

The check endpoint, receipts and shadow mode work today. Velocity and throttle rules ship behind flags that are off unless your policy turns them on.

Every receipt this job produces carries this grade:

Evidence grade Rung 2 · Operational

Covers

Which rule decided this request and that the record was not changed after signing. Not whether the sender was an AI agent.

Confidence

None stated. No calibrated confidence applies to this record.

Calibration

Uncalibrated

Known error rates

None measured. Silvector publishes no detection error rate yet.

Basis

• Deterministic decide() rule allow.default
• Ed25519 signature over the canonical receipt body, checked against the published JWKS

Bias risks

• The decision is only as good as the facts it was given. A request with no signature claim is not_identified, which is not a finding that a person or an agent sent it.

Next step

To ask who was behind a series of requests, keep the receipts and escalate to rung 3 with at least two independent signal families. How escalation works

Assigned by

These docs, from the rung definitions. The grade is not a signed field of the receipt.

Next