Most payment integrations begin as a pile of vendors. An account here, an FX provider there, a separate payout aggregator, a card programme, and a reconciliation spreadsheet holding the whole thing together. Each addition brings its own contract, its own credentials and its own edge cases — and the perimeter grows faster than the team that has to maintain it.

An API-first perimeter reverses the pattern. Instead of stitching together separate vendors, you call one interface that exposes accounts, FX, payouts and a double-entry ledger as a coherent surface. Related capabilities share a single identity model, a single policy layer and a single record of what happened.

What a perimeter actually contains

At the protocol level, a business unit is not one account but a set of connected capabilities:

  • accounts and balances, held with licensed partners
  • FX and conversion across roughly ten currencies
  • payouts on local rails, plus cards and card acceptance through licensed partners
  • a proprietary double-entry ledger, built on TigerBeetle, that attributes every entry to a principal, an agent and a policy version
  • signed, verifiable documents and per-unit reporting

For a developer, the practical benefit is that these are not five integrations. They are one contract with five surfaces.

Where agents and institutions enter

The input layer is deliberately plural. Humans use an interface; AI agents connect through an API, OpenAPI and MCP; institutions speak ISO 20022. The same operation — a payment, a conversion, a limit check — can originate from a person, a software executor or a bank without changing the accounting beneath it.

That matters because the perimeter is designed for operations that must remain attributable. An agent owns nothing and is never anonymous; every operation resolves to an identified principal.

What to plan for

Start with the flow you can describe precisely. The agent model runs in production on a platform of about 157,000 lines of code, so the primitives are settled rather than experimental. An agent unit costs $99 per year; platform embedding starts at $25,000 per year. Exact terms depend on the flow you bring.

Treat the first integration as a design exercise in policy, not only in code. Limits, approved counterparties and approval thresholds are configured below the model, where an agent cannot argue with them.

In short

  • One interface can replace several vendor integrations for accounts, FX, payouts and ledger.
  • Agents (API, OpenAPI, MCP) and institutions (ISO 20022) enter through the same input layer.
  • Every entry is attributed to principal, agent and policy version.
  • Policy sits beneath the agent, not inside its reasoning.

Build your first unit and see how one interface feels: developers.