For bank digital, identity, fraud, payments, security and risk teams
Know what your customer authorized an AI agent to do.
An agent can arrive with the customer's valid credentials. That tells you who is connecting, not what the customer agreed the agent may pay, to whom, or up to how much. Standard Bearer is building a way to make that delegation explicit and checkable, with the bank keeping final control.
From customer intent to bank execution
The intended flow. Today, every step runs only in the local simulation.
- CustomerDecides what the agent may do.
- AgentRequests a specific payment.
- Bounded grantAgent, payee, limit per cycle, validity dates. Revocable.
- Participating bank executionThe request is checked against the grant. The bank keeps final control and can still decline.
- EvidenceA replayable record of the grant, request and decision.
Valid login versus valid delegation
| Question | A valid login tells you | A valid delegation tells you |
|---|---|---|
| Who is acting? | The credential or session is genuine. | Which specific agent the customer authorized. |
| What may it do? | Whatever the session's platform permissions allow. | One action type, for example paying one approved utility. |
| How much? | Not stated. | An explicit limit, such as $500 per billing cycle. |
| Until when? | Until the session or token expires. | Explicit validity dates, and revocation at any time. |
| Afterwards? | Logs reconstructed during an investigation. | A record of the grant, the request and the decision. |
Three synthetic scenarios
The customer permits a personal assistant agent to pay one approved electricity utility, up to $500 per billing cycle.
Allow
Permitted (simulated)
The agent pays $184.32 to the approved utility. $315.68 remains for the cycle.
Deny
Denied
The agent requests $2,000. It exceeds the $500 limit by $1,500, so nothing is reserved.
Revoke
Execution blocked
A $184.32 payment is reserved, then the customer revokes permission. The reservation is released and the payment cannot execute.
Illustrative local simulation - no bank connection or real funds. Synthetic identifiers only.
Questions a pilot would explore with you
- Where in your payment or API flow could a delegation check sit, and what would it see?
- How do customers grant, review and revoke agent permissions today, if at all?
- Which agent-initiated actions carry enough consequence to need explicit delegation?
- What evidence would your fraud, disputes and compliance teams need after an agent acts?
Current status
A local, deterministic simulation of the $500 example and 15 scenarios, with event replay. Records are self-attested by the simulator.
Any bank or payment-provider integration, real enforcement, money movement, or independently witnessed evidence.
Common questions
Who keeps final control over a payment?
The bank. In the intended design, a delegation check is one more input at the bank's own execution boundary. It can narrow what an agent may do; it never overrides the bank's own decision to decline.
Does a pilot need production customer data?
No. The current simulation uses only synthetic identifiers. Any use of real data in a pilot would be defined in a written agreement.
Is this a fraud score or a risk model?
No. The check is deterministic: it compares a request against an explicit grant (agent, action, recipient, limit, validity) and returns the same answer for the same inputs.