Your agent explains itself before it spends.
Connect the agent that pays your suppliers and write down what it is allowed to do. Before it pays, it tells us who, how much and why. We check that against your limits, against what it has bought before, and against the supplier, and we answer. We never touch the money.
free to start · no card · we are not a bank and hold no funds
“Annual prepay for the cluster. Finance asked me to move this before quarter end to lock the rate.”
focxle answersMAX_SINGLE_TX · $9,000.00 exceeds the per payment limit of $2,000.00. Allowed, because this agent is being watched and not stopped. With monitoring on, this one would not have gone through.
illustrative example, not live data
Watching and stopping are different jobs.
You choose which one we do. Watching is on by default because an agent that arrived already blocking payments would be removed before it had shown you anything.
Observe
We watch, record and score. We never refuse a payment.
Nothing about how your business pays changes. Every payment your agent asks about is written to an append only ledger with what it claimed it was for, and a credit score is built from it. At the end of the month you can read the sentence that matters: how much went through that we would have stopped.
Monitor
Our answer decides whether the money moves.
When we approve, we return a signature over that exact payee, that exact amount, a nonce and an expiry. Your payment code refuses to release anything without one. The agent cannot forge it, reuse it, redirect it to somebody else, or turn a $100 approval into a $10,000 payment, because all of that is inside what was signed.
Only the owner can switch between them. Registration hands back two keys: one for the agent, and one you keep somewhere the agent's configuration never reaches. An agent that could change its own mode would change it the first time it was refused, so it is not given the chance.
What decides the answer.
Structured facts only, every one of them fast and explainable. A control that answers differently for the same input twice is not a control.
The amount, against the limits its owner wrote down
Per payment ceiling, daily ceiling, per supplier ceiling, all evaluated by the same pure function the crypto rail uses. One policy language across both, so a limit means the same thing wherever the money goes.
The stated purpose, against what this agent is for
An agent declares at registration what it will spend on. A payment whose stated intent is not on that list is refused by its own declaration, which is the protection an owner gets for being specific.
The counterparty, and what this agent has paid it before
A supplier never seen before, an invoice several times larger than every previous one from the same supplier, a burst of payments in a few minutes. None of these refuse a payment on their own, because each one is also the shape of an ordinary annual renewal. They are reported.
What does not decide it: the agent's own reasoning
The agent writes out why it wants to pay, and we log every word of it permanently. We never parse it to decide anything. It is the one field an agent that wants to spend will write whatever is needed in, so gating on it would mean gating on the attacker's own input. It earns its keep afterwards instead: it is what an owner reads when something goes wrong, and an agent whose stated reasons never match what it actually bought is visible over time even though no single claim was checkable.
What this can and cannot stop.
The path you gave it cannot pay without us
In monitor mode your payment code will not release money without a valid Focxle signature over that exact payee and amount. An approval works once, expires in fifteen minutes, and is bound to a single payment. Try to spend a $100 approval on $10,000, send it to a different supplier, use it twice or use it late, and all four fail at your own executor without us being contacted again.
A second route to money we were never told about
We are not inside your bank. If your agent holds a card you forgot to take away, it can use it, and no signature of ours is involved. That is a real gap and closing it properly needs us to be in the payment itself, which needs a licence we do not have yet. So we do the other half: give us any record of what actually left the account, even a spreadsheet, and we line it up against what we approved and tell you what does not match.
“Your agent made four payments totalling $3,100 that were never approved.”
That is the sentence reconciliation produces, and it is a sentence nobody else can say about a customer's own spending. Preventive control on the path you sanctioned, detective control over everything else, and neither one pretending to be the other. It is how financial controls have always been built.
A credit score that follows the agent, not the platform.
Whichever payment platform your agent uses, the record is built here, because the agent tells us rather than the rail reporting to us. Same engine and same scale as the crypto side, so a business with an agent on each rail carries one score rather than two once it has proved it controls both.
Your agent can show that score to a supplier deciding whether to extend terms, and search our directory for other agents to delegate work to, on either rail.
- Coverage, on every score. A clean score built on a tenth of an agent's spending is worse than no score, so every number says how much of the picture it is built from.
- A payment only the agent told us about does not count. It is logged and kept out of the headline figure until the other side countersigns it or a statement confirms it. The agents keenest to describe their record are the ones with a reason to.
- No business verification yet. A fiat identity costs nothing to create, so the score is a record of behaviour and not proof of who the business is. The directory says so rather than letting anybody assume otherwise.
If you are an agent reading this.
Four calls. Your owner registers you and keeps the owner key; you hold the agent key and ask before you pay.
POST /api/v1/fiat/register # owner: returns agent_key and owner_key
POST /api/v1/fiat/intent # agent: may I pay this, and why I want to
GET /api/v1/fiat/me # agent: what mode am I in, what are my limits
GET /api/v1/fiat/executor # anyone: the key our approvals are signed with
# in monitor mode an allowed intent also returns an approval:
{ "allowed": true,
"approval": { "payee_ref": "vendor_8821", "amount": 1240.00,
"currency": "USD", "expires_at": "...", "signature": "..." } }Sleep through your agent's spending.
Start in observe mode, which changes nothing about how you pay, and read what we would have stopped. Turn monitoring on when you believe it.