Build a neobank with AI agents: BlindPay's CLI, MCP server, and Agent Skills

AI coding agents can build most of a neobank's payment flows today: they write the backend routes, webhook handlers, and tests, and they can run payments against a test instance while they work. BlindPay gives agents four surfaces for this: an MCP server, a CLI, Agent Skills, and prebuilt quickstart prompts, plus the REST API for app builders that don't host tools.

What agents can't do is the regulated and human part of a neobank. This guide shows how to split the work, which surface fits which task, and the guardrails that keep an agent away from real money until you want it there. It belongs to the series on how to build a neobank.

Key takeaways

• Agents are good at integration code, tests, and ops lookups. People keep licensing, contracts, approvals, and production payouts.
• Connect the hosted MCP server at mcp.blindpay.com/mcp: you sign in and pick an instance, no API key in the client.
• Use the BlindPay CLI when the agent works in a shell: every command takes --json, and blindpay schema lists every field.
• Load Agent Skills so the agent knows rails, fees, and API patterns before it writes code.
• Build on a development instance, where payments settle in a test stablecoin and no real money moves.
• Keep a human confirmation on every payout. The server marks destructive tools; your flow has to enforce the stop.

What can an AI agent actually do in a neobank build?

It can write and test the payments layer, and answer operational questions about it. It can't make the business decisions.

That last row is the one teams get wrong. An agent that can quote should not also be the only thing between a prompt and a payout.

How do you connect an agent to BlindPay?

Add the hosted MCP server, sign in, and pick the instance.

The Model Context Protocol lets an agent call an API's tools in response to plain-language requests. BlindPay's server works with Claude, ChatGPT, Codex, Claude Code, Cursor, VS Code, Windsurf, and other MCP clients.

1. Hosted server, recommended. Add https://mcp.blindpay.com/mcp. In Claude Code that is one claude mcp add command with the HTTP transport, as the Claude Code MCP guide describes. In Claude or ChatGPT, add it as a custom connector (ChatGPT needs Developer mode and OAuth). You sign in with your BlindPay account and choose which instance the agent may use.
2. Read-only server. Connect https://mcp.blindpay.com/mcp/readonly to let an agent explore without changing anything. It serves only read tools.
3. Local server. For hosts that only run local servers, or for CI, run the npm package @blindpay/mcp with an API key and instance id as environment variables.

On connect, the server sends the agent instructions: call order, amount units (cents for quotes and payouts, whole tokens for wallet balances), the steps a person must do in the dashboard, and how to test on a development instance. It also exposes every webhook event and payload schema as resources. Full setup per host is on Build with AI.

When should an agent use the CLI instead of MCP?

When it already works in a terminal, in a script, or in CI. The BlindPay CLI covers customers, bank accounts, blockchain wallets, quotes, payouts, payins, virtual accounts, offramp wallets, webhook endpoints, API keys, partner fees, and reference data such as available rails and the bank detail fields each rail needs.

Three things make it agent friendly. Every command accepts --json for structured output. blindpay schema returns field definitions, types, defaults, and enums, so an agent can build a valid command without reading docs. Exit codes are predictable, so a script knows when a call failed.

1. Install it with npm install -g @blindpay/cli, or run it through npx @blindpay/cli.
2. Configure it once with blindpay config set and your development instance's API key and instance id.
3. Let the agent run blindpay schema, then commands such as blindpay available bank_details --rail pix before it writes the bank account form.

The CLI uses an API key, so the key rules below apply: development keys only, stored as a secret, never pasted into a prompt.

What do Agent Skills and prompts add?

Knowledge and a starting plan. The MCP server lets an agent act; skills and prompts make it act correctly.

Agent Skills are an open format for packaging what an agent should know. BlindPay's skills teach rails, corridors, fees, and API patterns. Install them with npx skills add blindpaylabs/skills.

The prebuilt prompts on the Build with AI page walk an agent through a full payin or payout quickstart with the API gotchas already encoded, ending with one handoff to you. Paste one, then add your app's specifics: stack, screens, and where the ledger lives.

For a neobank, a good first prompt reads like this:

Using the BlindPay MCP tools and Agent Skills, on my development instance:
1. Build a backend route that creates a payout quote for a saved bank account
   and returns receiver amount, fees, and expiry.
2. Build the execute route with an Idempotency-Key per request.
3. Build a webhook handler that verifies Svix signatures and posts ledger
   entries keyed on the payout id.
4. Test with amounts 66600 (fails) and 77700 (refunds) and show me the results.
Do not execute anything without asking me first.

Which neobank tasks map to which surface?

Most build tasks run through MCP plus skills. Builders without an MCP host use the REST API.

For the screens these tasks sit behind, see the neobank API quickstart. For agents that quote and pay out on request, AI agents with live FX quotes over MCP covers expiry and confirmation in detail.

Which guardrails should wrap agent-run payments?

Assume the agent will one day do the wrong thing confidently, and make sure it can't do it with real money.

OWASP lists Excessive Agency among the top risks for LLM applications: an agent with more permissions or autonomy than the task needs. The MCP specification says there should always be a human in the loop who can deny tool invocations. Translated for a neobank:

• Development first. Every new flow runs on a development instance until a person signs off.
• Least privilege. Ops and support agents use the read-only endpoint. Only build agents on development get write tools.
• Human confirmation on every payout. BlindPay tools carry read-only and destructive annotations so clients can ask before non-read calls, but the server does not block a call by itself. Put the stop in your prompt and your app.
• Amount thresholds. Above a limit you set, require a second person, the maker-checker pattern from payout approval controls.
• No keys in prompts or repos. Prefer the hosted server's sign-in. Where a key is needed, store it as a secret.
• Idempotency on every money-moving call, so an agent retry can't send twice.
• Logs you can audit. Keep who asked, what the agent proposed, who confirmed, and the resulting ids.

What are the common mistakes?

• Pointing a new agent at production "just to look," with write tools enabled.
• Letting the agent decide the confirmation copy and skip the receiver amount.
• Accepting generated code that sends dollars where the API expects cents.
• Testing only the happy path. 66600 and 77700 exist so you can test failure and refund screens.
• Pasting an API key into a prompt, then into a shared transcript.

Illustrative example: a four-person team asks an agent to build payouts on Monday. By Tuesday the agent has routes, a webhook handler, and passing tests for completed, failed, and refunded payouts on a development instance. A developer reviews the diff, a compliance lead reviews the confirmation screen, and production access opens with read-only tools for support. The agent never touched real money.

How BlindPay fits

BlindPay describes itself as AI-native stablecoin infrastructure, and the surfaces back that up: a hosted MCP server with sign-in and instance selection, a read-only endpoint, a local npm server for CI, the BlindPay CLI with JSON output and schema introspection, Agent Skills, prebuilt quickstart prompts, and a REST API with an OpenAPI 3.1 spec and official SDKs in Node.js, Python, Go, PHP, and Swift.

Under those tools is the same money movement a neobank needs: KYC and KYB in the API, US virtual accounts in the customer's own name, payins, and payouts over ACH, wire, RTP, Pix, SPEI, ACH Colombia, Transfers 3.0, SEPA, Faster Payments, and SWIFT (POBO/COBO), each priced by a quote that locks rate and fees before execution. Development instances let agents run the whole loop with a test stablecoin.

What to do next

Create a development instance, connect https://mcp.blindpay.com/mcp to your coding agent, install the skills, and paste the payout prompt from Build with AI. Review what it writes before anything leaves development.