What Kordio is
Kordio is the financial control plane: the rules and the record for money your software moves. It has two halves, and four words separate them. Control decides. Ledger records.
Kordio moves nothing and holds nothing. No custody, no rails, no execution, and none of your
credentials. Your own executor acts on Kordio’s answer, on your own rails, with your own keys.
That is the architecture, not a disclaimer: a control plane does not forward the packets.
Control works the way a preflight check works. Before your software pays a vendor, buys on a
marketplace, books a trip, or calls a paid tool, it asks. The answer comes back in the same
request: allowed, needs a person, or denied, naming the rule that decided and reporting the
headroom left on every limit. Allowed answers come back signed, so whatever executes can verify
the authority instead of trusting the caller that carried it. Kordio is a required signer, never
a custodian.
That governs any action type, not only payments, and it is not tied to a payment rail. An action
type is a dotted string like
payment.create, order.place, booking.create or tool.invoke.
Kordio never executes any of them, so nothing in the model assumes a card, a bank, a chain, or a
marketplace on the other side. One agent’s caps, windows and allowlists apply across all of them
together, so spend on one consumes headroom for the other.
The ledger underneath
Kordio Ledger is the other half: a double-entry system of record you write to over HTTP. Accounts, balanced postings, derived balances, point-in-time history, and reconciliation, period close, trial balance and account statements as first-class operations rather than reports you rebuild each month. It is a real general-purpose ledger rather than an audit log wearing accounting vocabulary, and you can use it on its own. Where a workspace has the ledger enabled, the reservations Control takes are mirrored into it as balanced postings, so agent spend and the books do not have to be tied together by hand later. The projection never sits in the authorization path, so a slow ledger cannot delay or change a decision, and a workspace with no ledger authorizes exactly the same way. Check Billing in the console for what your workspace has today.Is this for you?
Yes, if something other than a person can start a payment or a paid API call. A settlement job, a refund workflow, an agent buying supplies, booking freight, managing ad budget, or just burning through model and tool spend at a rate nobody predicted. You want a rule that runs before the money moves and a record afterwards that names what permitted it. That is spend control. Yes, if you also need an auditable money system of record. A treasury product, a marketplace splitting funds, an FX desk, a SaaS company billing its own usage. That is the ledger. No, if you only need bookkeeping for your own company’s taxes and statements. That is what accounting software is for.The decision boundary. The moment something non-human can initiate spend you would want to
review, you are at the layer this product serves. Before that, a hard-coded cap in your own code
is fine. After it, the question is not whether you have a control plane but whether it can be
bypassed, and whether it can prove what it permitted.
Next steps
Where a control layer fits
Why a prompt, an
if statement, a card limit, and AP2 each stop short.Why a ledger API
Versus Postgres, versus a processor, versus accounting software, versus the other ledger APIs.