Pockyt — Vision · 2026
Money should move
the way information does.
The infrastructure of global commerce is still built around a financial system designed for paper, branches, and correspondent banks. We're building what comes next: a programmable layer where money moves locally, settles globally, and exposes the same surface to humans, software, and the agents that will soon operate businesses on our behalf.
01 — Thesis
The next era of cross-border money movement won't be solved by a better filling.

For thirty years, the answer to "how do we move money across borders better" has been to put a smarter wrapper on the same underlying system. A faster front end on the same correspondent rails. A nicer dashboard on the same FX margin. A new vendor in the same chain of vendors. The filling changes; the box stays the same.

Pockyt is built on the opposite conviction. The box is what's broken. The chain itself — collection on one rail, FX with one provider, treasury at one bank, payout through another, reconciliation in spreadsheets glued underneath — is what extracts the cost, adds the delay, and limits what global businesses can actually build.

The next era of cross-border money movement won't be solved by a better filling. It'll be solved by a better box.

We are building that box. Not a payment processor. Not a treasury app. Not a remittance service. An operating layer — where collection, treasury, and disbursement are primitives in one programmable system, exposed through one interface, governed by one set of rules.

02 — Problem
The global payments stakc is a tower of vendors

Walk into any global merchant's treasury function and ask how money moves through their business. You'll hear about a payment processor for collections, a separate provider for cross-border FX, a bank in every operating market, a separate vendor for mass payouts, a compliance vendor on top of all of them, and an internal spreadsheet trying to reconcile the whole thing.

Each layer takes a margin. Each layer adds a delay. Each layer is a different API, a different contract, a different relationship to maintain. The merchant pays for the integration five times — once in vendor fees, once in engineering time, once in FX spread, once in capital trapped between settlements, and once in the operational overhead of running the chain.

What this costs the world

  • Capital trapped in transit. Funds collected in São Paulo on Monday may not be usable in Singapore until Friday. Multiply across every corridor a global business operates in, and you get hundreds of millions of dollars of working capital permanently in motion, earning nothing.
  • FX margin extracted twice. Most providers take a margin on the FX leg into their settlement currency, then another margin going out to the merchant's home currency. Two haircuts per cross-border transaction — invisible to the consumer, taxed against the merchant.
  • Markets left unserved. Local payment methods in growth markets — Pix, UPI, M-Pesa, GCash, Alipay — are not optional. Yet most Western payment stacks deliver them inconsistently, at the wrong economics, or not at all. The merchants who can't access them simply leave that revenue on the table.
  • Innovation blocked by integration. A treasury team that wants to programmatically route, hold, or convert money cannot do so today without writing custom code across five vendors. The intelligence stays in spreadsheets because the rails don't support it.
03 — The Shift
Three forces have made the operating-layer idea buildable.
The vendor-chain pattern persisted not because anyone liked it, but because the alternative wasn't possible. That has changed. Three independent shifts now make a unified operating layer for global money movement not just possible, but inevitable.

1. Stablecoins as a real settlement asset

USDC and its peers crossed a threshold somewhere around 2024. They're not a curiosity; they're a credible settlement instrument used by serious institutions, including ours. Stablecoins collapse a three-day correspondent-banking sequence into minutes, and they do it without asking the merchant to take crypto exposure. The end consumer never sees them. The treasury just settles faster, cheaper, and with one less intermediary.

2. In-country licensing and domiciled accounts at scale

The regulatory infrastructure for operating "globally local" — holding licenses, opening domiciled bank accounts, accepting funds at par in the merchant's name across many markets — used to be the exclusive territory of correspondent banks. It is no longer. A new generation of money-movement infrastructure is being built around the principle that local presence and global coverage are not in tension.

3. Programmable money — and the agents that will use it

Money movement has always been programmatic in theory and manual in practice. The intelligence sat in the operator's head, expressed through spreadsheets and reconciled by hand. A new generation of tools — and increasingly, AI agents acting on behalf of merchants — wants to operate on money the way it operates on data: through APIs, with rules, with deterministic outcomes. The infrastructure has to meet that demand or be bypassed.

04 — How we're built differently
Four primitives. One programmable layer.
Pockyt collapses what is normally a five-vendor stack into four primitives, exposed through one programmable layer.
The Pockyt architecture

Money in. Money held. Money out.
Threaded together by one programmable layer.

Checkouts handles every way money arrives — consumer checkout in 300+ local methods, plus B2B bank-rail collection into the merchant's virtual account. Virtual Accounts and Multi-currency Treasury hold value in 27 fiat currencies and USDC across 11 locally domiciled markets. Payouts move money out in any direction, on any rail. Programmable Logic is the connective layer that lets operators (and, increasingly, agents) define how it all behaves.

The stablecoin sandwich

The clearest expression of the operating-layer thesis is what we call the stablecoin sandwich. A Brazilian customer pays through Pix. The funds land at par in the merchant's domiciled BRL virtual account. Pockyt converts the balance to USDC at mid-market and lands it in the merchant's US treasury — or holds it on-chain, or routes it onward to a supplier in their native currency. One call. One ledger. One source of truth.

The traditional way to do this would have involved a Brazilian acquirer, a wholesale FX provider, a US correspondent bank, a payout vendor, and somewhere between three and seven business days. The stablecoin sandwich does it in minutes, at mid-market FX, with no working-capital lockup.

Why this isn't a payment processor

Payment processors compete on conversion at the front end and treat what happens after the swipe as someone else's problem. They are layered on top of an unchanged stack. The operating-layer model is different: we treat collection, settlement, treasury, and disbursement as a single coherent surface, governed by the same rules, exposed through the same API, settled through the same ledger.

This isn't a feature difference. It's a category difference. The right peers for Pockyt aren't payment processors; they're the infrastructure platforms reshaping their own categories — the ones treating their domain as something to be programmed, not transacted through.

05 — What we believe
Five claims about the future we're building toward.
Claim 01
FX margin is going to zero as a business model.
The half-point-here, two-points-there extraction that funds traditional cross-border payments is the kind of margin that only persists in opaque markets. Programmable, on-chain, mid-market FX makes it transparent — and once it's transparent, it compresses.
Claim 02
Local payment methods will be infrastructure, not features.
Pix, UPI, M-Pesa, and the next generation of real-time local rails will become the default way commerce happens in growth markets. The merchants who treat them as a checkbox lose. The ones who treat them as primary infrastructure win.
Claim 03
Treasury becomes a programmable surface.
Holding currency in 27 fiats and USDC, routing it through rules instead of through people, sweeping it on schedule or on signal — these become product features, not enterprise IT projects. The line between "money movement" and "operations" dissolves.
Claim 04
Agents will operate businesses, and they'll need rails.
Software agents — finance copilots, treasury automation, autonomous procurement — are coming faster than the payment infrastructure they'll rely on. The platforms that expose money movement as a machine-legible surface will be the ones agents reach for.
Claim 05
The winners build boxes, not fillings.
In every infrastructure category — compute, storage, networking, observability — the eventual winners weren't the players who optimized the existing stack. They were the ones who rebuilt the underlying primitives. Cross-border money movement is overdue for that rebuild.
Claim 06
The product is the API.
A merchant's experience of a money-movement platform is mediated entirely through code: their checkout, their backend, their treasury automation, the agents acting on their behalf. The product surface is the API. Marketing pages, dashboards, support — all of them are derivatives of how good that surface is.
06 — Where this goes
The horizon — and what's already real.

A vision that doesn't ship is a brochure. So here is the discipline we hold ourselves to: every piece of the architecture above is live today, in production, with paying customers. The horizon items below extend what's real; they don't replace it.

Already live

  • Virtual accounts in 11 domiciled markets, held in the merchant's name, denominated in local currency.
  • Multi-currency treasury across 27 fiat currencies plus USDC, with mid-market FX between them on demand.
  • Checkouts through 300+ local methods and B2B bank rails, terminating in the merchant's virtual account.
  • Programmatic payouts to banks, wallets, cards, and on-chain addresses in 100+ countries.
  • A hosted MCP server at docs.pockyt.io/mcp — the first one in our category, connectable from any MCP-compatible client.

What we're building next

  • First-class MCP tool definitions per endpoint — typed inputs and outputs for every operation, beyond today's documentation surface.
  • Deterministic preview and dry-run mode — simulate any state-changing call and get the full projected effect, with zero side effects. This is the foundation for safer agent-driven money movement.
  • Per-key capability scopes — restrict an integration or an agent to specific operations, environments, or value bands.
  • Structured "why" traces on every transaction — routing decisions, FX provenance, applied rules. Money movement that is auditable by humans and agents alike.

The kind of company we're building to be

The companies that built durable infrastructure in the last twenty years had three things in common: they treated their primitives with care, they published their reasoning, and they earned trust by being right about the future earlier than their category accepted. We are trying to be that kind of company in money movement.

Not the loudest. Not the easiest. The one teams will look at five years from now and recognize as having been correct about what money movement was about to become.

Build with the box,
not on top of the filling.

Talk to our team about how Pockyt fits behind your product, your platform, or the agent layer you're building.