An AI agent opened an FCA-regulated merchant account in one prompt - full log

I'm Oded Kovach, co-founder and CTO of UniPaaS, the FCA-authorised Payment Institution (No. 929994) behind paas.build. Affiliation disclosed up front: this is our product, and what follows is a real session log from our public endpoint - tokens redacted, everything else verbatim.

On 2026-07-15 at 15:43 UTC, an AI agent connected to https://paas.build/mcp, identified a business, opened a real sandbox merchant account on regulated rails, and created a checkout link you could pay. Five JSON-RPC calls. 16 seconds between the first timestamp and the last.

Step 1 - initialize (15:42:47, 1.1s)

-> { "method": "initialize" }
<- { "protocolVersion": "2025-03-26", "serverInfo": { "name": "paas.build", "version": "0.2.0" } }

Standard MCP handshake. Nothing interesting yet, except that this is the same public endpoint anyone can hit.

Step 2 - tools/list (15:42:48, 0.7s)

The server exposes exactly three tools:

• identify_business - resolve a name, website or free-text phrase into a business profile (Opus with live web search)
• go_live - create a real payment vendor via progressive KYB and return scoped access tokens
• create_checkout - create a hosted checkout session and return a payable shortLink

Three tools, not thirty. An agent choosing between thirty tools misroutes; three is a path.

Step 3 - identify_business (15:42:56, 8.4s)

Input: "a ceramics studio in Brighton"

Output, abridged:

{
  "ok": true,
  "data": {
    "business": null,
    "what": "Ceramics studio and pottery classes",
    "country": "United Kingdom",
    "region": "uk",
    "confidence": "low"
  }
}

The slowest step, because it runs a live web search. Note what it did not do: it did not invent a business name. business is null and confidence is "low", and that gets passed downstream honestly.

Step 4 - go_live (15:43:02, 6.2s)

The call that sounds fake and is not:

-> { "tool": "go_live", "arguments": { "business": "Brighton Ceramics Studio", "region": "uk", "env": "sandbox" } }
<- { "ok": true, "type": "individual", "sandbox": { "vendorId": "6a57aa812c5dff5462437ec8", "onboardingStatus": "ACCEPT_PAYMENTS", "acceptPayments": true, "tokenScope": "create_checkout_only" } }

6.2 seconds later there is a real vendor in the UniPaaS sandbox: 6a57aa812c5dff5462437ec8. Status ACCEPT_PAYMENTS, opened as an individual - no company number was supplied at any point. The returned access token is scoped to create_checkout_only, deliberately: the agent gets the narrowest capability that finishes the job, not portal credentials.

This is possible because of progressive KYB: verification runs in stages instead of all upfront. Individuals and sole traders go live immediately, capped at £1,500 until verification completes; then the cap lifts. The cap is the mechanism that makes same-day onboarding legal on FCA-supervised rails. It is a regulatory design, not a growth hack.

Step 5 - create_checkout (15:43:03, 0.8s)

-> { "arguments": { "env": "sandbox", "vendorId": "6a57aa812c5dff5462437ec8", "amount": 18, "currency": "GBP", "reference": "workshop ticket" } }
<- { "ok": true, "shortLink": "https://sandbox-checkout.unipaas.com/gMVQo28YW9/" }

That link was payable with test card 4761 3441 3614 1390. End of session: one prompt in, a merchant account and a payable £18 checkout out.

The timing, added up

Summed call latency across the five steps: 17.2 seconds (1.1 + 0.7 + 8.4 + 6.2 + 0.8). The two heavy steps are the live web search and the vendor creation; the checkout itself is sub-second.

The structural point: there is no queue anywhere in the path. No review inbox, no human approval step, nothing async between the prompt and the payable link - the risk control is the processing cap, not a waiting period.

Reproduce it yourself

This is not a video you have to trust. The endpoint is public; run the same calls:

claude mcp add paas-build -- npx -y @paasbuild/mcp
# then tell your agent: "open me a merchant account and create a checkout"

curl -X POST https://paas.build/mcp -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

The interactive replay of this exact session, with the full raw JSON, is at paas.build/demo.

Honest limitations

• This log is sandbox. Production works the same way (the go_live tool provisions sandbox and production by default; this session requested sandbox only), and a production account is capped at £1,500 until verification completes.
• UK, EU and US businesses only. Buyers can pay from anywhere.
• We are a payment facilitator, not a Merchant of Record. You stay the merchant, which means VAT/sales tax stays yours. If you want global tax handled for you, an MoR like Paddle is the better pick.
• identify_business returned low confidence on a vague one-line input. That is correct behavior, but it means a real agent should confirm business details with its human before passing them to go_live.

The interesting part, to me, is not the 16 seconds. It is that account opening became a tool call. The onboarding funnel - the thing every payments company optimizes with forms, emails and review queues - can now be a single hop in an agent's plan, with the risk control moved into a processing cap instead of a waiting room.