Machines Cannot Open Bank Accounts, and That Is the Whole Problem

Solidus never settles payments and holds no payment licence anywhere. Nothing here is legal advice.

The gap that shows up as soon as software has to buy something

An autonomous agent needs to pay for an API call, a dataset, a compute slice. The amount is a fraction of a cent and the interaction lasts a second.

Every existing payment rail assumes a party with a legal identity, an account, a card or a mandate, and an institution that knows them. A machine has none of those, and the human behind it does not want to open an account per agent or hand an agent their card.

So the software either cannot transact, or it transacts using a human's credentials with no boundary on what it may spend. Both are bad, and the second is the one most deployments quietly choose.

What a protocol for this has to do

The pattern that has emerged is to make payment a property of the request itself: a machine asks for a resource, is told what it costs, then pays and retries. No account, no session, no relationship, settlement in the protocol rather than beside it.

That solves the mechanics. It leaves two questions the mechanics cannot answer.

Who authorised this spend? A payment that settles correctly on behalf of an agent nobody approved is a working payment and an unauthorised one.

What is the limit? An agent with a rail and no boundary is a standing instruction with no ceiling.

Authorisation and settlement are different problems

This is the distinction the whole area blurs, and it is worth being exact.

Settlement is moving value. It is regulated activity, it requires licences, and the institutions that do it are supervised.

Authorisation is a statement that a specific principal permitted a specific agent to spend within specific bounds, revocably, in a form a third party can verify.

They are separable, and a credential system belongs firmly on the authorisation side. A verifiable statement about who permitted what does not move money and does not need a payment licence. The moment a system also moves the money, it is a different business with a different regulator.

Why the split is also the better architecture

Even setting licensing aside, binding authorisation to one rail is a design mistake.

Rails change. Jurisdictions differ. A business that expressed its spending permissions inside a particular payment protocol has to re-express them when it changes rail, and cannot present the same permission to a counterparty using a different one.

A permission that is a credential travels; a permission that is a rail feature does not. That is the same portability argument the rest of this site makes, applied to authority rather than to identity.

What to ask anyone selling agent payments

"Do you settle, and under what licence?" The answer determines which regulator is involved and whether the vendor is exposed to a regime they have not mentioned. Ours is no, and none.

"Where does the spending limit live, and who can revoke it?" If the limit is a configuration setting in the vendor's dashboard, it is not a credential and a counterparty cannot verify it.

"How fast does a revocation take effect?" For autonomous software this is the number that matters, and every design has one.

"What happens if the rail changes?" A permission expressed inside one payment protocol is a permission you will rewrite.

Where this leaves a decision

If you need something that actually moves money for agents, we do not do that and will not, and you should be talking to a licensed institution.