Cards under each agent
Each card has its own shop and its own ceiling. Add more cards at any time.
A bank account for your AI agent
Built on the Machine Payments framework. Each AI agent gets its own small account under your name, and the bank issues card numbers only against a task you gave. Each number works at one shop, up to one ceiling. The agent can pay, and it never holds your keys.
A preview of the product. It is not yet available.
-
Your instruction becomes the card
No task means no number. A page can talk a model into wanting something, but it cannot forge an instruction you never gave.
-
Your identity, never your keys
The agent pays under your checked identity, from its own pot. It has its own key, and it never sees your card or your login.
-
The rules live inside the bank
Your caps, categories and approvals run at the bank, on every payment. The agent cannot argue with them, and no shop changes anything.
Travel agent
€426.00 in the pot
Demo, test money
DisposableLive
VISA
•••• 3567
Locked to Air ExampleUp to €200.00
Your task: “book flights, under 200, by Friday”
Try it at the demo shop
This card works at one shop, up to one ceiling. It dies after one purchase or in 30 minutes.
Each agent gets its own 
pot under your name, a 
card locked to one shop, and your 
hold above the line you set.
The instruction becomes the card
“book flights, under 200, by Friday”
You give the agent one task, in your own words.
The bank turns it into one number, locked to one shop and one ceiling.
The number is the mandate
A card payment carries very little: a shop, an amount and a kind of shop. It cannot carry a sentence like "book flights under 200". With an ordinary card, that leaves two poor choices. You trust the agent with everything, or you approve every purchase yourself.
Machine Payments moves the check. The bank reads your instruction first, then issues a number locked to it. The number carries your instruction to the shop, on the card rails that shops already use.
| Your own card in an agent's hands | An agent with Machine Payments | |
|---|---|---|
| Who the bank sees | You. The agent is invisible. | An agent, with a real customer's identity behind it. |
| What it can spend | Everything the card can reach. | Only what is in its pot, inside your caps. |
| Where the number works | Any shop that takes the card. | One shop, up to one ceiling, for minutes. |
| A page tricks the agent | The agent has what it needs to pay. | No task means no number, and nothing to pay with. |
| The number leaks | It works until you cancel your card. | A used number is dead. A wrong shop burns it for good. |
| A payment fails | A vague decline. The agent retries or gives up. | A reason code and the data to act on it. |
| Something feels wrong | You cancel the card you use every day. | One hold freezes every agent. Your own cards keep working. |
| A dispute starts | Your word against the shop's. | Three lines to read: your task, the payment, the shop's confirmation. |
See it in the app
One owner, from the first deposit to the final record: money in, a new agent, a card, a payment, a burned card, an approval and the Trust tab. The film uses test money and simulated shops. It has no sound, and it runs at about twice real speed.
The Machine Payments framework
A framework that a bank embeds. It gives every AI agent a small, rule-bound account under its owner's name.
It is not a service. It runs inside the bank's own perimeter, so no customer data and no funds cross a boundary. The framework decides, then it asks the bank to act. It never holds, moves or touches money.
The framework owns
- The account profile and its lifecycle
- Gate one and gate two, in their fixed order
- Task binding and expiry
- Reason codes and their meanings
- A sentence the owner can read, for every event
- Signature checks and replay protection
The bank owns
- The money, in its core ledger
- The database
- The card issuing platform
- The customer approval channel
- Customer identity and onboarding
- Every regulated activity
Why the rules arrive as working code
A written specification would leave every bank to build the same engine differently. Ten banks would give ten subtly different behaviours, and an agent would need a new integration for each one. So the framework ships the behaviour itself. The same request gets the same answer at every conformant bank, and an agent developer integrates once.
What it is made of
- Account
- The agent's pot. It opens under an existing bank customer, so identity is inherited and no new onboarding happens. It has no path to the main account, because the framework has no operation that could reach it.
- Policy
- The rules, written by the owner in plain choices and enforced by the bank: caps per purchase and per month, allowed kinds of shop, a tell-me line and an ask-me line. Gift cards, money transfers and crypto on-ramps stay off unless the owner opts in.
- Task
- The owner's recorded instruction: one sentence, a category, a ceiling and a time window. This is the answer to fraud against agents, and the answer is structural.
- Number
- A card number issued against a task, locked to one shop with one ceiling. A single-use number dies after the purchase. A standing number serves a subscription, and a price rise beyond its ceiling becomes a question for the owner.
- Payment
- One attempt to take money. It ends one of three ways: authorized, parked for the owner, or declined with a reason.
- Approval
- The parked state. The bank's own prompt asks the owner. Approval resumes the same payment, and silence declines it.
- Record
- The task the owner gave, the payment the bank made and the confirmation the shop returned, held together. A dispute is then decided by reading, not by argument.
- Feed
- Every event as a sentence for the owner. Consent the owner cannot read is not consent.
Travel agent may spend up to 300.00 per purchase and 600.00 per month, on flights and hotels; tell me above 20.00; ask me above 180.00.
Nothing can hang forever
Every object with a lifetime carries an expiry, because a machine flow that can hang forever will hang forever somewhere. These are the framework's defaults.
30 min
A single-use number that nobody used
2 hours
An approval that the owner did not answer
48 hours
A task the owner recorded
12 months
A standing number for a subscription
Who it serves
Owners
Set the lines once, in plain choices. Read every event as a sentence. One hold stops every agent.
Agent builders
Integrate once and work with every conformant bank. An agent reads what remains before it buys, and each refusal gives it a code to act on. The same request key never pays twice.
Banks
Embed the framework inside the perimeter, connect four systems and keep every regulated activity. No shop has to change.
Two gates, in a fixed order
Gate one runs when the agent asks for a number, and it has full context. Gate two runs when the shop asks for money, and it has only what a card authorization carries.
A rich check where the data is rich, a narrow check where the data is thin.
Requests
Gate one
Gate two
Paid
Ask
The agent asks for a number. Gate one checks the task, the category, the caps and the balance, always in that order.
Lock
The number works at one shop, up to one ceiling, for a short time. No task means no number.
Pay
The shop asks for money. Gate two checks the number, the shop and the amount. A wrong shop or a high amount burns the number.
Gate one, when the agent asks
- Agent key checks out
- Account is open
- Task is still valid
- Task fits this purchase
- Category is allowed
- Shop is not denied
- Inside the per-purchase cap
- Inside the monthly cap
- Pot has enough money
Gate two, when the shop asks
- Number is live
- Shop matches the lock
- Amount is inside the ceiling
- Account is open
- Inside the monthly cap
- Pot has enough money
- No approval needed
Why the order never changes
The first failure wins, and it returns exactly one reason. Without a fixed order, two banks could answer the same refused request with different codes, and an agent that branches on the code would behave differently between them.
One refusal, three readers
A vague decline is right for people. For a machine it is waste, because the machine retries blindly or gives up. So the reason goes to the agent and the owner, and the shop learns nothing.
The agent reads
SHOP_MISMATCH
The number is burned. Ask for a new one.
The owner reads
a gift card site tried 50.00 · gift cards are off by default · number burned
The shop reads
Declined
An ordinary decline, with no reason.
Inside the app
Caps, categories and an ask line, in plain choices. The bank enforces them on every payment.
Small parts, real rules
Single use, then dead
A leaked number is worth nothing.
Freeze in one tap
Stop a card now, and turn it back on later.
A wrong shop burns it
The shop sees only a normal decline. The agent and the owner see the reason.
A code for each refusal
Gift cards, money transfers and crypto on-ramps are off by default.
The two-in-the-morning button
One hold freezes every agent. You can undo it.
Every event is a sentence
Consent the owner cannot read is not consent.
Ask in your own words
The assistant opens the place in a floating tab. It cannot move money.
Trust you can check
The Trust tab shows how the app is built, how it protects you, and the rules its AI follows. It rests on the three pillars of the SEE framework.
Structured Modularity
Every part has one job and speaks through one versioned contract. An optional part can stop, and the others keep working.
Embedded Cybersecurity
Sealed files, signed agent requests and an append-only log with a hash chain. Verify now checks every line.
Embedded AI Governance
A refused list runs first, each voice decision keeps a record, and people decide every high-risk action.
0
paths from an agent's pot to your main account
1
key for each agent. A new key kills the old one, and only the old key can install a routine new one.
5 min
is the most a signed request may be off the clock. A repeated nonce fails too.
2
purposes for your task records: authorizing payments and evidencing disputes. No marketing, profiling, credit decisions or sale.
What a bank connects, and what it keeps
Four connections
- Its database, for accounts, tasks, numbers and records.
- Its ledger, where the pot is a real ring-fenced balance under the customer.
- Its card issuing, where the shop lock and the ceiling become real controls on the card.
- Its approval prompt, the one it already sends under Strong Customer Authentication.
A bank writes no policy engine, no reason codes and no order of checks. Those arrive ready.
Two levels of conformance
- Level 1, the account: a machine account under an existing customer, a ring-fenced balance, rules enforced at authorization, single-use and standing numbers, ask-me-first, freeze and revoke, and the readable feed.
- Level 2, the governance: all of Level 1, plus the agent credential, task recording, both gates with intent binding, the fixed order, reason codes, expiry, bound records and task privacy.
Level 1 uses parts a bank already has. Neither level needs a shop to change anything.
Rules no bank may change
- The order of checks at both gates
- The reason codes, and which condition gives which
- The signing rules and replay rejection
- The list of shop categories
- A burn on a wrong shop or a high amount
- The same request key never pays twice
Limits, expiry windows, branding and transport stay the bank's choice.
Where the framework stops
It stops at the payment. Refunds, returns and disputes travel the bank's existing card rails and processes, exactly as they do today.
The framework makes payment available to a machine, under rules a person set and can read, and it does nothing on anyone's behalf afterwards.
Questions
What is Machine Payments?
A framework that a bank embeds. It gives each AI agent a small, rule-bound account under its owner's name, and it decides every payment at two gates. The bank keeps the money, the customer and every regulated activity.
Can an agent reach my main account?
No. The pot has no path to the main account, because the framework has no operation that could reach it. Money enters the pot only when the owner moves it.
What happens if a card number leaks?
A wrong shop or an amount above the ceiling burns the number at once, and a burned number never works again. A used disposable number is already dead, so a breached shop database holds nothing of value.
Why is a real person behind each agent?
The pot opens under an existing bank customer, so the agent takes that person's checked identity. No new onboarding happens, and that person sets every rule.
Who holds the money?
The bank, in its own ledger. The framework runs inside the bank, and it never holds or moves money.
What does an agent learn when a payment fails?
It gets a reason code and the data to act on it, such as the cap and what remains. The shop gets a normal blank decline and learns nothing.
What if the owner does not answer?
The payment waits until its time limit, two hours by default, then declines by itself. The money moves only after the owner's hold.
What does the bank do with my tasks?
Task records have exactly two purposes: authorizing payments and evidencing disputes. They are not for marketing, profiling, credit decisions or sale, and the bank keeps them no longer than the dispute window.
Can voice or AI move money?
No. The assistant opens places and answers questions. It refuses a request to read a card number, and it has no way to approve or send a payment.
Do shops need to change anything?
No. The framework needs no change at the shop. The checks run at the bank, on the card number that the shop presents.
Can I use it today?
Not yet. This page shows a demonstration with test money, test cards and simulated shops. No licensed bank, card issuer or Visa product offers it today.