Bridge AP2 / x402 agent-payment mandates into wire-valid ISO 20022 pain.001 / pacs.008 records.
ap2-iso20022 MCP Server
The io.github.sebastienrousseau/ap2-iso20022 MCP server bridges AP2 (Google’s Agent Payments Protocol) and x402 (Coinbase’s HTTP-402) payment mandates into ISO 20022 wire records, specifically pain.001 and pacs.008. It provides guardrails for spending-cap, expiry, and authorisation, turning agent authorisations into settlement messages.
🛠️ Key Features
Bridge AP2 and x402 mandates into ISO 20022 pain.001 / pacs.008
Spending-cap, expiry, and authorisation guardrails
MCP server providing access to the bridge via tools
Latest release referenced: v0.0.1
🚀 Use Cases
Convert agentic-payment authorisations into the bank-rail messages that settle payments
Produce ISO 20022 records for workflows requiring pain.001 / pacs.008 output
⚡ Developer Benefits
5 MCP tools over stdio (per readme excerpt)
Pure-Python implementation (only mcp is noted)
Developer-oriented mapping from authorisation mandates to settlement formats
⚠️ Limitations
Source excerpt does not describe behavior beyond the pain.001 / pacs.008 bridge and listed guardrails
Detailed tool names/count beyond “5 MCP tools” are not included
Bridge AP2 (Google's Agent Payments Protocol) and x402
(Coinbase's HTTP-402) mandates into ISO 20022 pain.001 / pacs.008 records —
with spending-cap, expiry and authorisation guardrails, and an MCP
server. These agentic-payment protocols authorise a payment; this library
turns that authorisation into the bank-rail message that actually settles it
— the rail the card networks and stablecoins don't cover.
Latest release: v0.0.5 — 11 MCP tools over stdio, streamable HTTP or
SSE, pure-Python (only mcp), 100% branch coverage, for Python 3.10+. Output feeds straight into
pain001 / pacs008 to generate wire-valid XML.
Part of the ISO 20022 MCP suite.
Why
An agent with a signed AP2 mandate (or an x402 payment authorisation) can prove
it's allowed to pay — but nothing in those protocols emits the pain.001 a
bank needs to move the money. ap2-iso20022 is that missing hop. And because
moving money is consequential, it only transforms and validates — producing
the ISO record is deliberately separate from generating and sending it, so the
actual payment stays an explicit, guarded step.
Install
sh
pip install ap2-iso20022
# or run the MCP server without installing:
uvx --from ap2-iso20022 ap2-iso20022-mcp
2026-07-28 (stateless, server/discover) and 2025-11-25 (initialize, Mcp-Session-Id) on the same endpoint; responses stream as server-sent events, GET opens the server-to-client stream
ap2-iso20022-mcp --transport sse
HTTP+SSE (2024-11-05)
http://127.0.0.1:8000/sse and /messages/
for clients that still expect the older transport
--host and --port change the bind address (defaults 127.0.0.1 and
8000). The HTTP transports carry no authentication of their own: bind
loopback, or put the server behind a gateway you trust before binding a
routable address. Every release is verified over streamable HTTP with
scout in both protocol
eras and over SSE with the MCP SDK client; see
ADR 0001.
to_pain001 — Canonical mandate → pain.001 record (customer credit transfer).
to_pacs008 — Canonical mandate → pacs.008 record (FI-to-FI).
The output field names and types match what pain001 / pacs008 expect
(validated against their JSON schemas), so to_pain001(mandate) → pain001
generate_message → XSD-valid pain.001 with no glue.
Guardrails
check_mandate returns {ok, violations, warnings}:
required fields — payer/payee name + account, amount, currency
spending cap — amount <= max_amount when a cap is present
expiry — refuses an expired mandate when you pass as_of
authorisation proof — warns when no proof_type/proof_value is present
It never moves money; it tells you whether the mandate is safe to act on.
The suite
Part of a family of vendor-neutral, Python-native ISO 20022 MCP servers:
iso20022-mcp — unified gateway across the families.