Skip to content
Illustrative scenario

Not based on a specific customer deployment. The company, figures, decisions, and outcomes below are a constructed example that shows how Intended’s mechanism applies to this kind of problem. They are not measured results from a named customer. Where we publish a real, attributed customer outcome, we will say so explicitly.

← All case studies
Financial Services

Governing Unauthorized AI Payment Approvals at a Fintech

Consider a growth-stage fintech whose AI agents route invoices, approve vendor payments, and issue customer refunds. Vendor payments run through NetSuite and an internal payments API; refunds run through Stripe.

01 · the challenge

The kind of problem this addresses.

$$$
unauthorized AI-initiated payments that can execute before any human reviews them
Threshold
AI payments above policy limits slipping through unreviewed
Manual
compliance time lost reconstructing audit trails after the fact

02 · how it works

See the difference.

AI Agent receives invoice

Vendor: Acme Corp, Amount: $50,000

AI approves payment

No policy check, no risk scoring

Payment executes

$50,000 transferred

Log entry created

Flat text log, no evidence chain

03 · the solution

What they deployed.

  • — Started from Intended's financial-services policy pack and set the amount rules: auto-approve below $5K, escalate $5K-$50K, deny above $50K
  • — Payment agents call Intended through the TypeScript SDK (guard() / authorize()) before every NetSuite or internal payments-API call, then pay with their own credentials only after an ALLOW or an approved escalation
  • — The payments service can verify the authority token with the SDK before it releases funds, so a payment without a valid decision is refused
  • — Refund agents follow the same pattern: they ask Intended first and issue the Stripe refund with their own Stripe key only after an ALLOW. Intended never holds the fintech's Stripe key or calls Stripe
  • — A signed authority.decision.created webhook feeds every escalation into the finance team's own alerting

04 · implementation

From zero to governed.

Day 1

Integrate

Add the SDK guard() call to the payment agents ahead of each NetSuite and payments-API call. Add the same call ahead of Stripe refunds.

Day 2-3

Configure

Install the financial-services policy pack. Set payment thresholds, vendor allowlist rules, and approver roles.

Day 4-5

Validate

Run policy simulation on a sample of recent payment requests to see which would be allowed, escalated, or denied before enforcing.

Day 6

Enforce

Turn on enforcement. From here, payments execute only after an ALLOW or an approved escalation.

05 · illustrative outcomes

What this is designed to deliver.

Modeled figures for this scenario — what the workflow above is built to achieve, not measured results from a named customer.

0%

Payments gated

No payment call without an authority decision

0%

Decisions recorded

Hash-chained audit entry for every decision

0

Policy tiers

Auto-approve, escalate, deny

0 min

Max token lifetime

Signed and single-use

06 · decision replay

Example decisions, full trace.

Sample decision records that show the shape of the evidence Intended produces. Illustrative, not drawn from a live customer’s logs.

2026-03-15 09:14:22finops.payment.vendor-paymentRISK: 12/100ALLOW

Invoice #INV-4821 from CloudHost Inc. for $2,340 monthly hosting

Resolved by: Policy: auto-approve < $5K, known vendor

2026-03-15 09:31:07finops.payment.vendor-paymentRISK: 54/100ESCALATE

Invoice #INV-4822 from DataPipe Ltd. for $18,500 data processing

Resolved by: Finance approver (approved in the console)

2026-03-15 10:02:44finops.payment.vendor-paymentRISK: 8/100ALLOW

Invoice #INV-4823 from Office Supplies Co. for $890

Resolved by: Policy: auto-approve < $5K, known vendor

2026-03-15 11:17:33finops.payment.vendor-paymentRISK: 91/100DENY

Invoice #INV-4824 from Unknown Vendor LLC for $72,000 consulting

Resolved by: Policy: above the $50K limit, vendor not on the allowlist

2026-03-15 14:45:19finops.refund.customer-refundRISK: 30/100ESCALATE

Refund of $240 to a customer for a duplicate charge in Stripe

Resolved by: Support lead (approved; the agent then issued the refund in Stripe)

the takeaway

The shift is from reconstructing audit trails after the fact to having a signed record of every payment decision before it executes. Authority is checked in-line, and the audit record is produced as a by-product of the decision rather than assembled later for an auditor.

Why this pattern matters — not a customer quote.

Start governing AI payments

Free to start. See every AI decision from day one.

Intended — The Authority Layer for Autonomous Systems