# APPEN

> Programmable payment cards. You write the rules; the card enforces them on everything that
> spends — an AI agent, a script, a pipeline, or you.

## Canonical facts

APPEN is a card product of Blind Billing LLC, St. Louis, Missouri. It is not a bank.

The core of the product is a rule engine with **fourteen rule kinds**: thirteen declarative kinds
plus `webhook_check`, which hands the decision to an endpoint you own. The thirteen are
`merchant_lock`, `merchant_block`, `mcc_block`, `amount_ceiling`, `spend_cap`, `velocity`,
`time_window`, `max_uses`, `cooldown`, `approval_threshold`, `new_merchant_review`,
`per_merchant_spend_cap` and `duplicate_charge_guard`.

The engine evaluates a **declared purchase intent** — what something says it is about to buy —
rather than an authorization that has already happened. It returns one of four verdicts with a
per-rule audit trace: approve, decline, review (a human must say yes), or partial.

**Every rule runs on every intent.** The engine does not stop at the first failure, so a decline
comes back with all of its reasons rather than only the first. Only `webhook_check` is skipped,
and only once a local rule has already declined.

**A human approval gate is not a bypass.** Approving satisfies the gate rules alone; every other
rule still has to pass on its own.

## How a purchase is actually stopped

The card holds $0.00 until a rule says yes. A tap against an empty card declines on insufficient
funds at the issuer, before any decisioning system is consulted. When the rules approve, a
single-use card is funded to the approved amount and swept afterwards.

Eight of the fourteen rules are enforced by funding. Five require merchant identity, which only
exists inside the authorization message, and are enforced by issuing a fresh single-use card per
approved intent plus category controls at the processor. That is a blast-radius limit rather than
an authorization-time rule.

A zero balance is not a guaranteed decline: network stand-in processing is mandatory and can
approve without seeing the live balance, so a loss reserve is required.

## Why intent-time rather than authorization-time

Published external-decisioning windows: Stripe Issuing 2 seconds, Highnote 2 seconds, Galileo
2 seconds, Marqeta just-in-time funding 1–3 seconds, Lithic ASA 6 seconds. Each of them decides
on your behalf if you are slow — Stripe calls it Autopilot, Highnote calls it stand-in, Galileo
calls it fallback. A human approval step cannot fit inside that window. Moving the decision to
before the purchase exists is what makes one possible.

## Status, stated plainly

Card issuing is **not live**. There is no executed program agreement and no BIN. There are no
customers and no revenue. The rule engine is built, tested and running today, and there is a
sandbox that runs it in the browser with no account.

The issuing path runs through a US partner bank and a major card network; both are under
NDA and will be named at launch. Nothing is executed, so this is the path being
pursued rather than a live program.

## Who it is for

An individual who wants a governed card for their own agent, a subscription, or a family member.
A small business that wants genuine programmable control without an enterprise contract.
A programme — a food bank, relief fund, or stipend — that hands money to a client for a restricted
purpose and has to report where it went.

## Links

- Sandbox, no signup: https://getappen.com/sandbox
- How it works: https://getappen.com/how-it-works
- The fourteen rules: https://getappen.com/rules
- For agents: https://getappen.com/agent.txt
- Docs: https://getappen.com/docs