The two questions

Your fraud models score the cardholder. Who scores the agent?

When an agent initiates a payment on a cardholder's behalf, your authorization and fraud systems see the transaction, not the agent's mandate. They can't tell you whether the agent did more than the human authorized, or produce a record of why the charge was allowed. That's the verdict and the evidence BladeRun feeds you.

01

Did it overstep?

Cap, payee, purpose, expiry, aggregation, did the agent exceed what the cardholder actually authorized?

02

Can you prove why?

A signed, replayable record of the mandate and the verdict, examiner-followable, attached to the authorization your systems already make.

The primitive

One bound, scoped session per agent.

01

Verify

Any agent credential, or fingerprint when none.

02

Bind

To the mandate the cardholder authorized.

03

Enforce

Deterministic allow, step-up, or block.

04

Prove

Signed, replayable, under your keys.

We verify; we don't issue. A decision input that feeds your authorization and fraud systems, it doesn't replace them.

How it plugs into your authorization stack

One inline call, before you authorize.

One S2S call

Inline at authorization

Your decisioning calls BladeRun before it authorizes, a deterministic verified-agent verdict, in single-digit milliseconds.

Next to your signals

You keep the decision

The agent verdict sits alongside your existing fraud and risk signals. You keep the authorization decision.

Nothing routed through us

An input, not a proxy

No traffic redirected, no re-platform, out of the payment path. An input to your decision, not a proxy in front of it.

Neutral by design

You issue on one network. Agents arrive from all of them.

Across every rail

Or none at all

Any card network, open banking, or none (fingerprint). We verify the agent regardless of which rail it rode in on.

The signal your models lack

The overstep verdict

Your models are trained on cardholder behavior, not agent mandates. We add the one signal they can't produce: did the agent exceed its authority.

Evidence for the exam

Under your keys

Signed, replayable, examiner-followable, held under your keys, not on a public chain.

Questions banks ask

Straight answers for risk, compliance, and security.

Do you replace our fraud engine or our identity provider?
No. BladeRun is a decision input. It produces the one verdict your fraud models and IAM cannot: did the agent exceed the mandate the human authorized. It feeds the stack you already run; nothing to rip out.
Does this sit in our authorization path? What does it cost us in latency?
It runs off the payment authorization path. One inline server-to-server call returns a deterministic verdict in single-digit milliseconds; the heavier behavioral scoring runs asynchronously and never gates the approval.
Where does our data live?
In your environment, under your keys. Self-hosted in your VPC or a dedicated single-tenant VPC, with an in-region option. Signed evidence writes to your S3 and your KMS. Nothing on a public chain.
Is it defensible to an examiner?
There is no safe harbor, and we never claim SR 26-2 mandates agent controls, examiners still act on unsafe or unsound practice. What we give you is the evidence trail they follow: a deterministic, auditable mandate check and a signed, replayable record of every allow and every block.
Is the enforcement deterministic, or a black-box model?
The guarantee is deterministic. The mandate engine returns the same verdict for the same input, every time, auditable line by line. The one generative model in the system only writes the after-the-fact narrative, it has zero authority to allow, block, or escalate.
How fast can we stand up a pilot?
Start in shadow mode on one boundary. First verdicts and signed evidence in days, reversible by a routing rule, no commitment.
What happens if BladeRun is unreachable?
Fail-open or fail-closed, your policy, set per action class.
How do banks buy this?
Banks self-host; enterprise, by inquiry. It starts with a 1-hour meeting with the founders, then a written scope.
A technical pilot

One decision element. One pilot.

01

Working session

One hour. Map where agent-initiated transactions already hit your stack, and where we plug in. No commitment.

02

Signal pilot

Light up agent-trust on the authorization path for a set of boundaries. Measure lift and latency.

03

Decision element

Score the verified-agent verdict inline and attach the signed record to the authorization.

The overstep verdict your authorization stack is missing.

Neutral across every network. You keep the decision.

Start a technical pilot