Loading
Platform · Agentic Payments
Agents decide. Mesta settles.
Your software already decides who gets paid, how much, and why. We turn those decisions into settled money — payroll, suppliers, sellers, treasury — landing in local-currency accounts in 40+ currencies, under our licenses and regulated partners. $2.1B settled to date. Now we’re opening those rails to your software.
The shift
Software is about to make far more payment decisions than people ever did.
Sourcing, negotiating, invoicing, approving — the work upstream of a payment is being automated fast. Every bit of that automation ends in the same place: money has to actually move, to a real account, in a country with its own rules.
That last step doesn’t get easier as intelligence gets cheaper. It stays exactly as hard as it is today — and there is about to be far more of it.
We built the part that carries it. Now we’re making it something software can operate directly.
Running today
The engine is already built to be driven.
Every payment here already executes as software: fixed steps, version history, built-in approvals. Opening that to your agents is an interface project, not a rebuild.
150 versioned workflows
Every payment executes as a versioned workflow across our services and provider network. Every step is recorded, so any payment can be reconstructed end to end — and human approval is available as a step inside the flow.
Intelligence already in the loop
We read and validate invoices and onboarding documents against each destination country’s requirements, reconstruct failed payments across services and propose the fix, and assist compliance review at volume.
A licensed last mile
40+ currencies, fiat and stablecoin rails, into a real account in local currency — under licenses that took years to earn.
The architecture
How an intention becomes settled money.
Three layers. A request gains certainty at each one, and arrives as money in an account on the other side of the world.
01
Intent
What should happenAn outcome gets described — by your backend, an operator, or a model reading an invoice. This is the layer where intelligence works: extracting, mapping, drafting, investigating.
Document extractionField mappingDraftingInvestigation
Models work here. The two layers below are code.
02
Control
What is permittedThe request meets identity, limits, corridor eligibility, funding and approvals. It leaves this layer bounded, attributed, and recorded — or it does not leave at all.
IdentityLimitsCorridor rulesFundingApprovals
Now it is an authorized instruction, with its bounds attached
03
Settlement
What actually movesQuote, route, disburse, confirm, reconcile — across licensed fiat and stablecoin rails, into a real account in local currency, reconciled to the cent against what the provider says happened.
QuoteRouteDisburseConfirmReconcile
What cross-border actually demands
The hard part was never calling the API.
These are the constraints that decide whether an automated payment lands or sits in an investigations queue for nine days. Each one shapes how we build.
01
A purpose code is a regulatory declaration
India, Brazil, South Africa, Vietnam, Indonesia and Korea all require a purpose-of-payment code. The wrong one gets the payment returned — or creates a problem for the person receiving it.
How we build for it
Purpose codes are a constrained, per-corridor enum, validated before submission. A model can suggest one. The enum is the only author.
02
A valid plan can still be impossible
A run scheduled Friday afternoon misses the local RTGS window and lands after a public holiday somewhere else. Several currencies cannot be priced at all outside their local session.
How we build for it
Cut-offs, value dates and settlement calendars are a validation layer, not a footnote. We reject an impossible plan before it becomes a stuck payment.
03
Repair is a data problem, not an FX problem
An IBAN check digit, a wrong CLABE branch code, an invalid IFSC, a missing tax ID. A small share of every cross-border book needs human intervention, and it is the largest driver of operations work.
How we build for it
A field-level error taxonomy the whole platform shares. The model reads the rejection and proposes the corrected field; deterministic validation checks it; a person applies it.
04
What was sent is not what arrives
Charge-bearer terms and intermediary deductions decide what actually lands. “My supplier received 19,955 instead of 20,000” is the most common complaint in this business.
How we build for it
We model the guaranteed amount separately from the amount sent — so a promise about what lands on the other side is a commitment we can hold, not an estimate.
05
The beneficiary is not our customer
We screen a person we have no relationship with, on data our customer supplied. When software supplies the payee, where that payee came from becomes a compliance question.
How we build for it
Every payment will carry the history of its recipient — which system proposed it, under which permission, approved by which person — as an exportable record.
06
Liquidity runs out mid-run
A partner’s local balance falls short halfway through a payout run. Failing the whole run is wrong. Continuing blindly is worse.
How we build for it
Hold the affected corridor, keep the others moving, alert treasury, resume on funding — with per-payment state that makes the partial position legible.
Where this goes
What your software will be able to hand us.
Not one payment at a time. Whole processes, run repeatedly, adapting as the inputs change.
Payroll that runs itself
A roster changes, the run adapts. Rejected rows get repaired against the destination country’s rules. You approve once, and each month lands without anyone assembling a file.
Invoice to settled payment, end to end
An approved invoice becomes a validated recipient, a funded run, a routed corridor and a reconciled payment — with the purpose code, tax identifiers and beneficiary fields that country requires already correct.
Treasury that acts on its own signals
Balances rebalanced across corridors ahead of a cut-off rather than after it, on the conditions you set, with every movement authorized and reconciled like any other payment.
Marketplace payouts at the moment of earning
Sellers paid as revenue clears rather than on a weekly batch, across dozens of countries, without your team growing to match the seller count.
What we’re building
Opening the engine to your software.
Three layers, in the order we're opening them.
01
The tools — MCP and Agent Skills
Mesta over the Model Context Protocol, so any MCP-compatible agent calls us as typed tools — with Agent Skills alongside, carrying the knowledge that is genuinely hard to get right: which corridor supports which payment type, what a beneficiary needs in each country, how to recover from a rejection.
- High-level tools shaped around outcomes — not 104 endpoints wrapped one-to-one
- Read and quote openly; anything that moves money sits behind a mandate
- Authorization checked on every single tool call — by our infrastructure, not by the agent’s good behavior
- Errors that name the offending field, so an agent corrects itself in one turn
02
The workflows layer
Define a payment process once — recipients, eligibility, funding, approvals, limits, corridors — then run it on a schedule or on demand. Every run reconciled, every payment tracked individually, every failure repairable without failing the run.
- One definition, versioned and approved before it can execute
- A run paying ten thousand recipients is still one reviewable object
- A durable guarantee that a retry never becomes a second payment
03
Mandates — the authorization layer
KYC and KYB don’t go away — mandates sit on top of them. We bind an agent’s signing key to a KYB-verified legal entity and a named human, then issue a signed, scoped, revocable mandate stating exactly what it may do — and above what amount a person must approve.
- Limits by amount, velocity, recipient, corridor and expiry — evaluated in code
- Approval bound cryptographically to the exact artifact that was reviewed
- Narrow or revoke authority instantly, including for runs already scheduled
- Every payment carrying provable evidence of who permitted it, and within what bounds
In shipping order
What we’re shipping, in order.
First a capability every customer gets. Then the product you buy.
Every payment explains itself
“Where is my money and why did it fail” — ends here. A field-level reason and its repair options, on every payment. It ships first: no new money movement, and the engine behind it already runs our floor.
PaymentFailed
purpose code — required by the destination rail · missing
repair proposed from the rail’s own enum · validated ✓
Apply repair →
The Workflows API
Define a payout process once — recipients, checks, approvals, limits. Run it as one reviewable object, on schedule or on demand, and approve it in one signature. Payroll, supplier runs, marketplace payouts and treasury are this product wearing four names. It works with the plain API calls your backend already makes — agents are one more way to drive it. It ships second.
Workflow · payroll-monthly · v3Awaiting signature
run #08 · 397 payments · every check passed
limits passed · releases on signature
Review & sign →
Illustrative product UI
The mandate
A document, not a token.
The key says who is calling. The mandate says what the call may mean — and it is a document your auditor and your bank can read, not a secret in a config table.
Mesta payment mandate · illustrative
{
"mandate_id": "mdt_0f2e51",
"principal": { "merchant": "payroll-platform-inc",
"kyb_status": "verified" },
"authorizer": { "user": "head-of-treasury",
"webauthn_credential": "cred_9a44…" },
"agent": { "identity_type": "registered",
"agent_id": "agt_7c21",
"key_thumbprint": "kZ0nR…" },
"constraints": { "per_payment_max": "25,000 USD",
"budget": "150,000 USD / rolling 30d",
"allowed_corridors": ["US→MX", "US→BR"],
"approval_threshold": "10,000 USD" },
"expires_at": "2026-12-31",
"revocation": { "registry": "…/v3/mandates/revocations" }
}Signed by the named human’s passkey at issuance; evaluated at the rail on every call; revocable in one call, including runs already scheduled. And when Know Your Agent arrives in phases 4–5, exactly one field changes: the agent slot accepts an externally-attested credential instead of our key. One slot changes — not the architecture.
The MCP tools
Every read open. Every write named.
Authority escalates from Read to Act — and stops at a person before money moves.
Read
Open on connect. Everything Mesta shows, readable.
- Check a corridorcorridors.check
Is this corridor live, on which rails, with what cut-offs.
- Know what a payout needsbeneficiaries.requirements
Every field this country’s payout needs, before you build the form.
- Get a guaranteed quotepayments.quote
A guaranteed landing amount, not an estimate.
- Track the moneypayments.track
Where the money is — and why, in language you can act on.
- Find any operationapi.search
Find the right operation for the job, anywhere in the full API.
- Read anything Mesta showsapi.read
Call any read operation the platform offers. Everything Mesta shows, an agent can read.
Draft
Side-effect-free. A draft can be wrong safely.
Connect
Point your agent at Mesta.
Agent-readable docs
curl https://docs.mesta.xyz/llms.txt
104 operations, indexed for machines. Paste this into any agent today.
MCP — three doors
{
"mcpServers": {
"mesta-docs": { "url": "https://mcp.mesta.xyz/docs" },
"mesta-sandbox": { "url": "https://mcp.mesta.xyz/sandbox",
"auth": { "type": "api_key" } },
"mesta": { "url": "https://mcp.mesta.xyz",
"auth": { "type": "api_key" } }
}
}Three doors, in the order you’ll use them. Docs — no key needed. Sandbox — rehearse the full flow before any money exists. Production — read tools open on connect; every write defers to a person, on keys you already hold. Paste-ready the day they ship; design partners get them first.
One-line install
claude mcp add --transport http mesta https://mcp.mesta.xyz codex mcp add mesta --url https://mcp.mesta.xyz
One line for Claude Code, one for Codex — and anything that speaks MCP connects the same way. Both go live the day the doors open.
The control plane
Controls with names.
Shipping with the tools.
150 versioned workflows
Deterministic execution is how the platform already runs — every payment, every day.
Signed mandate
A signed mandate binds an agent’s key to a KYB-verified entity and a named human — authority you can prove, not a key and a hope.
Hard limits
Amount, velocity, recipient, corridor, expiry — enforced at the rail, not in the prompt.
Approval packets
The packet’s hash is what the passkey signs — swap anything and the signature dies.
Instant revocation
One call ends an agent’s authority — including runs already scheduled.
The audit trail
An exportable record per payment: who asked, what was permitted, who approved, what settled. Built for the person whose job is to ask.
Every approval packet carries a TTL — unsigned by its deadline, it is void, not pending.
What your software inherits
$2.1B
Settled to date
0+
Payout currencies
0+
Fintechs in production
Why this compounds
Intelligence is getting cheap. Regulated rails are not.
Models get better and cheaper every month. Licenses, banking partners, local corridors, compliance operations and liquidity do not — they take years, and they accumulate.
So we don’t intend to win on having the cleverest model. We intend to win by making the scarce part — moving money across borders, correctly, under a license — something software can operate safely and prove afterwards. Banking partners will require a human release above a threshold; we designed for it before being asked — and that design is the shape SAFR, the industry’s framework for agentic finance at runtime, now describes.
Every year that passes adds corridors, partners and settled volume to one side of that ledger. Nothing resets it. That is the side we’re on.
Every category, one control plane
The map, drawn honestly.
New agent platforms launch at zero — no volume, no licenses, no customers. Ours launches at $2.1B settled to date, 50+ fintechs in production, an AI layer already working our own floor.
Move
Cross-border payments
40+ payout currencies, fiat and stablecoin rails — settled into real local bank accounts under our licenses and regulated partners.
Fiat-to-fiat transfers
Currency to currency, account to account, on the same rails.
On-ramps
From fiat into stablecoin without leaving the platform.
Off-ramps
From stablecoin into local currency, delivered to the beneficiary’s bank account.
Store · Grow · Spend
Store
Virtual accounts
Hold and organize balances on-platform — the store layer your payouts fund from.
Store
Self-custody wallets
Store value in wallets you control, connected to the same rails.
Grow
Stablecoin yields
Put idle balances to work between payouts.
Spend
Stablecoin cards
Spend platform balances directly.
Every category, designed to be operable through the same four objects: mandate, workflow, run, record.
FAQ
Whose agent, whose money, whose signature.
Whose agent runs the payout — yours or ours?
Yours — under your mandate, with your named human signing the release. The same governance path will serve an agent you run and, later, agents we operate for you: the mandate doesn’t care whose process is calling; it cares who is accountable.
What can my agent do today?
Read our entire API — docs.mesta.xyz serves llms.txt now, and the 104-operation API is live for your backend. The MCP doors — docs, sandbox, production — ship next.
Do agents ever hold funds?
No. On Mesta an agent holds authority, never an account. Your business holds the funds, a mandate you sign will define what software may do with them, and a named human releases anything that moves money. That is the shape regulated cross-border requires — and the one your bank’s risk team will recognize.
How does human approval work?
In the first release, an agent’s write is deferred: it becomes a pending request a person approves in the dashboard before it executes, with webhooks for every state change and an explicit expiry. That gate then upgrades: approvals become packets whose hash a named human signs with a passkey, so what was approved is provably what was reviewed.
Which agents and platforms will be compatible?
Anything that speaks MCP — Claude Code, Codex, Cursor, custom backends — plus plain HTTP for everything else; underneath, it is all the same API. Agent Skills will carry the corridor knowledge — which fields Brazil requires, what a purpose code means, how to recover a rejection — so your agent arrives already knowing the hard parts.
Agentic payments
Be one of the first to build on it.
Bring us the flow you want automated. We’ll show you what settles today, and shape the tools around what you need.