Understand the two primary RTP message flows: the credit push (pacs.008 Customer Credit Transfer) moves funds from sender to receiver instantly; the Request for Payment (pain.013) asks the payer to authorize a credit push — no funds move until the payer approves
For credit push: construct a pacs.008 message with required fields (creditor account, debtor account, amount, end-to-end ID) and submit via your RTP-connected bank's API; expect a pacs.002 acknowledgment within seconds
For RFP: send a pain.013 to the debtor's routing/account; the debtor's FI presents it to the account holder; if accepted, a pacs.008 flows back to you automatically; if declined, you receive a pain.014
Handle pacs.002 negative acknowledgments (rejection codes) for the credit push: map rejection reason codes to user-facing messages and implement retry logic only for transient errors (e.g., system unavailable), not for hard rejects (e.g., invalid account)
Reconcile by end-to-end ID: both credit transfers and RFP responses carry the same end-to-end identification you assigned; use it as the idempotency and matching key in your ledger
Known gotchas
RTP transaction limit is $10M (raised in February 2025); amounts above this are rejected — validate before submission rather than relying on network rejection to catch oversized payments
RTP operates 24/7/365 with no settlement windows; unlike ACH, there is no concept of a cutoff time, but your sponsor bank may impose its own API availability windows
The end-to-end ID you assign must be unique per transaction; reusing an ID for a retry on a different payment can cause the receiving bank to treat it as a duplicate and reject it
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp