How U.S. Payments Really Work Part 13
‹‹ How U.S. Payments Really Work ››
How U.S. Payments Really Work Part 13
‹‹ Series Overview ››

RTP: Real-Time Payments With Real-World Bottlenecks

The rail that’s ready for the future—but held back by the past.

Suma Manjunath
Author: Suma Manjunath
Published on: September 05, 2025

RTP: Real-Time Payments With Real-World Bottlenecks

Audience: Backend engineers, fintech architects, and payment system developers
Reading time: 15 minutes
Prerequisites: Familiarity with ACH, ISO 20022, and payment APIs
Why now: With RTP adoption hovering around ~65% of U.S. DDAs in 2025, developers must grapple with real-world integration before scaling instant settlement.

TL;DR:

⚠️ Disclaimer: All scenarios, accounts, names, and data used in examples are not real. They are realistic scenarios provided only for educational and illustrative purposes.

Problem Definition

The bottleneck: RTP was launched in 2017 to provide sub-second, irrevocable payments. Yet, as of 2025, only ~65% of U.S. demand deposit accounts are reachable, and even then, most banks expose inconsistent, proprietary APIs.

Who faces this: Fintechs, payroll processors, insurers, and enterprise payout systems trying to deliver instant funds availability.

Cost of inaction: Without RTP adoption, firms fall back to ACH delays, risk higher fraud exposure with cards, and lose ground to global peers where instant payments are standard.

Why current approaches fail:

Solution Implementation

Overview

RTP is not “plug-and-play.” Developers must integrate via banks, BaaS providers, or fintech infra platforms. Success requires:

Step 1: Direct Bank Integration (Enterprise)

import requests
import datetime

# Example RTP Credit Transfer (via bank-provided API)
payload = {
    "routing_number": "061000052",   # Bank of America (example)
    "account_number": "123456789",   # Receiver account
    "amount_cents": 12500,           # $125.00
    "currency": "USD",
    "transaction_id": "RTP20240817A1",
    "beneficiary_name": "John Doe",
    "remittance_info": "Invoice 20240817"
}

try:
    response = requests.post(
        "https://api.jpmorgan.com/rtp/credit_transfer",
        json=payload,
        headers={"Authorization": "Bearer YOUR_OAUTH_TOKEN"}
    )
    response.raise_for_status()
    print("✅ RTP Transfer Success:", response.json())
except requests.exceptions.HTTPError as e:
    print("❌ RTP Transfer Failed:", e.response.text)

💡 Tip: Always validate against pacs.002 status messages, not just synchronous HTTP 200 responses. Banks may accept a request but later reject at clearing.

Step 2: BaaS Abstraction (Fintech-Friendly)

// Example RTP payout via Moov API
import fetch from "node-fetch";

const payout = {
  account_number: "123456789",
  routing_number: "061000052",
  amount: 12500, // in cents
  description: "Vendor settlement 20240817",
  trace_id: "TXN20240817001"
};

async function sendRTP() {
  try {
    const res = await fetch("https://api.moov.io/v1/rtp/send", {
      method: "POST",
      headers: {
        "Authorization": "Bearer TEST_API_KEY",
        "Content-Type": "application/json"
      },
      body: JSON.stringify(payout)
    });

    if (!res.ok) {
      throw new Error(`❌ RTP Error: ${res.statusText}`);
    }
    const data = await res.json();
    console.log("✅ RTP Payout:", data);
  } catch (error) {
    console.error(error.message);
  }
}

sendRTP();

ℹ️ Note: Moov, Increase, Treasury Prime, and Unit normalize RTP across banks, sparing developers from ISO 20022 parsing and fragmented onboarding.

Step 3: Ledgering & Reconciliation

-- Example: Reconciliation table
CREATE TABLE rtp_ledger (
    txn_id VARCHAR(32) PRIMARY KEY,
    amount_cents INT NOT NULL,
    account_number VARCHAR(12) NOT NULL,
    status VARCHAR(20) NOT NULL,
    processed_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- Insert successful RTP txn
INSERT INTO rtp_ledger (txn_id, amount_cents, account_number, status)
VALUES ('RTP20240817A1', 12500, '123456789', 'SETTLED');

❗ Warning: Never assume RTP = ACH with faster speed. Real-time finality requires instant ledger updates. If your ledger lags, you risk double-spending or misreporting balances.

💡 Tip: Add retry logic with idempotency keys and circuit breakers to prevent retries from creating duplicates when bank APIs time out.

Validation & Monitoring

Testing: Simulate both successful (pacs.002 = Accepted) and rejected (pacs.002 = Rejected) messages.

Success Metrics:

Failure Modes:

Risk Management in RTP

❗ Warning: There are no chargebacks in RTP. Fraud prevention must be real-time and pre-transaction, not post-settlement.

Adoption Metrics (2024–2025)

Metric Value (2024)
RTP volume 343M transactions
RTP value $246B
Adoption by banks ~65% of DDAs reachable (~71% technical reach)
Certified institutions 675+
Cost per transaction $0.01–$0.25 (B2B)
Messaging standard ISO 20022
Notable adopters Paychex, Venmo (via banks), Zelle, insurers

The Economics of RTP Adoption

💡 Tip: Evaluate RTP adoption with a TCO model: direct bank build vs. BaaS vs. waiting for FedNow scale.

Ecosystem Gaps That Block RTP Adoption

ℹ️ Note: These gaps explain the rise of infra players (Moov, Increase, Treasury Prime): they standardize bank chaos into developer-friendly APIs.

Takeaways

Acronyms and Terms

References

Share this article:

At BuildTales.dev, Suma Manjunath is passionate about writing, intentional tech, and the messy magic of building great software teams.

If you enjoyed this article, explore more stories in these series:

  • 💳 Payments Series – ACH, card networks, faster payments, wallets, crypto
  • 🧭 Leadership Series – Systems thinking, organizational growth, decision-making
  • 🏗 Systems Series – Architecture, resilience, scaling patterns for software engineers

Comments & Discussion

Share your thoughts, ask questions, or start a discussion about this article.