How Banks and Networks Communicate During Payments

Send money to a friend on an app, and then wonder what happens next. Your transfer doesn’t just “move” magically. It becomes a secure set of instructions that has to travel through banks and networks.

Knowing how payments are communicated helps you understand why some transfers are fast, why fees vary, and why fraud checks exist. It also explains why newer rails use message formats like ISO 20022 as a shared language.

In 2026, that language shift matters more than ever. You’ll see how banks package payment details into structured messages, send them over networks like SWIFT and instant payment systems, and confirm settlement end to end.

The Common Language Banks Use for Payments

Think of a payment like a package. If the shipping label is vague, the route takes longer. If it’s detailed and clear, handlers can sort it faster and with fewer mistakes.

That’s the job of a payment messaging standard. It tells the next bank what to do, where to send the money, and what the payment is for. In 2026, the big upgrade is ISO 20022, which uses structured data instead of older, looser formats.

Here’s the practical advantage. With ISO 20022, banks can include richer fields like sender details, payment purpose, and remittance information. As a result, systems can automate matching and tracking. Errors drop, and investigations get easier when something looks off.

The shift also supports faster payment behaviors, because modern rails want clean “machine-readable” data. When every bank speaks the same dialect, fewer transfers stall at handoffs.

You can see this in where ISO 20022 is already common:

  • FedNow and RTP in the US use ISO 20022 message specs directly for instant payments.
  • Fedwire Funds Service fully switched to ISO 20022 in 2025, with banks reporting faster processing and better tracking.
  • SWIFT is in a long migration. Reports show it’s around 65% on the new structured approach by March 2026, with a full shift expected by late 2026.
  • ACH still uses older net-style formats, so ISO 20022 adoption isn’t clear there.

If you want a deeper look at the “what you need to know” view of ISO 20022 for US instant payments, FedNow’s own explanations are a helpful starting point: FedNow ISO 20022 overview.

Modern illustration of structured data packets representing ISO 20022 payment messages flowing between two bank icons over a network, with arrows indicating direction in a blue-green palette on subtle gray-white gradient.

Just as important, structured messages help with fraud. Banks can run checks on fields that used to be missing or harder to interpret. For example, a payment purpose code can steer risk rules, instead of guessing.

If you like the “why now” angle, ISO 20022 message definitions are publicly documented here: ISO 20022 message definitions.

ISO 20022: The Global Standard Taking Over

ISO 20022 messages are not just “more data.” They’re organized data. Instead of cramming everything into fixed text blocks, the standard breaks information into structured elements with clear meaning.

So when your bank sends instructions, the message can include:

  • Unique IDs for the payment so banks can track it
  • Payment type and purpose so the receiver understands intent
  • Remittance information so “what this is for” stays attached
  • Sender and beneficiary details so reconciliation is easier

On modern rails, that structure also makes it easier to support real-time workflows. When settlement needs to happen quickly, there’s less time for manual fixes.

In practice, ISO 20022 also helps cross-border automation. When the message format is consistent, banks can map fields across systems more reliably. That means better routing decisions and clearer audit trails.

Also, the standard isn’t only for “big banks.” It’s the language that payment providers and processors can align on too. That’s why you’ll see ISO 20022 referenced across instant payment initiatives.

In the US, the result is clear: FedNow and RTP can process messages quickly because they don’t need constant translation. Meanwhile, SWIFT’s migration shows why change takes time. Banks don’t switch overnight because they have years of legacy tooling, compliance controls, and reconciliation logic.

If you want an example of how FedNow frames ISO 20022 message specs in plain terms, this resource is useful: FedNow ISO 20022 message specifications.

Other Key Protocols in the Mix

ISO 20022 is the common language, but it’s not the only thing you’ll hear about. Payments still rely on older formats and rail-specific rules, especially in the US.

Here are a few key players you’ll see in real payment flows:

  • SWIFT MT and SWIFT MX: SWIFT is primarily a messaging network. MT is older and MX is newer. During the migration, many flows still combine both.
  • Fedwire Funds Service: This is a US real-time gross settlement service for large-value transfers. It switched fully to ISO 20022 in 2025.
  • CHIPS: Another high-value US payments platform. It moved to ISO 20022 in hybrid mode for certain flows.
  • ACH: A large US mass-payments system. ACH processing is often batch-oriented, and the messaging model doesn’t rely on ISO 20022 in the same way.

If you’re trying to understand how these options differ by timing and purpose, a non-technical comparison like RTP, FedNow, and ACH compared can help you connect the dots without getting lost.

One point to remember: messaging standards affect speed and clarity, but timing also depends on how the rail settles.

How Domestic Payments Flow Between Banks

When people ask how payments work, they usually mean domestic transfers like app-to-app money movement. In the US, those flows often travel through a mix of bank systems and payments rails, guided by real-time rules.

Your transfer gets packaged by your bank, sent as a message over the network, then matched to the receiver bank’s instructions. Finally, settlement locks in.

However, the timing depends on which rail carries the message. Some rails move payments in seconds. Others clear in batches.

A simple view helps. Your bank does four things, even when the details vary by system:

  1. Send the payment instruction with routing and account details.
  2. Transmit it across the network using that rail’s messaging rules.
  3. Have the receiver bank verify and credit the funds.
  4. Settle the transaction so both sides balance their ledgers.

If you’re used to ACH, think “batch mail.” If you’re used to instant payments, think “real-time courier.”

For a quick visual of a domestic instant flow, here’s the idea in picture form.

Modern illustration of a simple flowchart for US domestic real-time payment flow: sender bank to RTP/FedNow network to receiver bank, with four icons for phone app start, message send, verification, and settlement, connected by arrows in a clean blue-green palette.

Real-Time Speed with RTP and FedNow

Real-time payments feel instant because settlement happens fast, and messaging supports quick follow-through. In the US, RTP and FedNow are the two names most people run into.

RTP is run by The Clearing House. In February 2026, it hit a record 2.05 million payments on one day. Across that same period, it averages over 1 million payments per day and settles quickly, with 24/7/365 availability for eligible payments.

FedNow is the Federal Reserve’s instant payment service. In Q2 2025, it reached 2.1 million total payments, up sharply from Q1. RTP still dwarfed it, but both are built for fast settlement.

So what’s the message flow inside a real-time rail? Here’s a clean 4-step model:

  1. Pay: You initiate a transfer inside an app.
  2. Send the ISO message: Your bank creates structured payment instructions and sends them through RTP or FedNow messaging.
  3. Verify and credit: The receiving bank checks the instruction and credits the account.
  4. Confirm and settle: The system settles so the transaction becomes final.

Meanwhile, banks run fraud rules during those seconds. They can screen fields like payment purpose or sender patterns. Some rails also support quick holds and blocks when risk signals appear.

One more concept you’ll hear is Request for Payment (RFP). That’s when a merchant or biller sends you a payment request through your bank or app. Then your bank can route the payer side and attach the right reference data. Instead of “guessing,” the payment includes clearer intent.

If you want a readable explanation of how RTP and FedNow work, this business-focused guide is a solid companion: Understanding real-time payment networks.

Slower but Steady: ACH Batch Transfers

ACH is the system behind many payroll and bill payments. It’s huge, and it’s reliable. Still, it usually isn’t “instant.”

ACH often runs as batch processing. That means payments are grouped and sent through clearing windows. As a result, your money typically posts the next business day, even if same-day options exist for some payment types.

In other words, ACH is great when timing is flexible. It’s efficient for large volumes. It also tends to have predictable cost.

In early 2026, ACH got extra attention due to new fraud labels for certain payment types starting March 20. Originators must add labels like PAYROLL and PURCHASE to standardize data and fight fraud. That change shows how messaging quality affects risk controls, even on older rails.

If you want a practical comparison of rails by speed and fit, these kinds of explainers can help you choose what matters for a business case: Real-Time Payments vs ACH.

Here’s the gotcha to keep in mind:

Instant rails can still reject payments if verification fails.
Speed isn’t the same thing as guaranteed approval.

So when your payment doesn’t land quickly, it may be a risk block, a verification mismatch, or a posting rule at the receiving bank.

Crossing Borders: International Payment Paths

International payments add a new layer: more than one bank might handle your money along the way. Even if your bank sends the instruction, correspondent banks often help route funds across countries and currencies.

The message part still matters. It has to include details for routing, compliance, and remittance info. ISO 20022 increasingly supports this, but legacy messaging and local rules still play a role.

In practice, cross-border wires can take days. That delay comes from correspondent steps, banking hours, and settlement cutoffs. However, improvements help a lot.

One of the biggest upgrades is SWIFT gpi, a faster tracking and fee transparency program built on SWIFT messaging. With gpi, many transfers now show status updates and arrive much sooner than old “send and wait” wires.

Tool results for March 2026 show this picture:

  • Nearly 60% of gpi payments arrive in under 30 minutes
  • Most arrive in 24 hours or less
  • 4,000+ banks use gpi
  • About 1 million payments daily, across thousands of country paths and currencies
Modern illustration of global payment network with SWIFT lines connecting five bank icons across continents on a subtle world map, data paths in blue-green palette.

The SWIFT Network Journey Step by Step

SWIFT is often described as “the network.” But it’s more accurate to call it a messaging backbone. Your bank uses SWIFT to send standardized payment instructions to other banks.

A typical wire journey looks like this:

  1. Your bank creates the message
    It formats your payment instruction and assigns identifiers. Many flows use message types like MT for wires during the migration era.
  2. SWIFT routes it to banks in the chain
    The network delivers the message securely to each participant.
  3. Compliance and checks happen at each step
    Banks screen against sanctions, fraud signals, and internal policies.
  4. Final credit and settlement complete the transfer
    Once settlement happens, the payment becomes final.

A step-by-step explainer like this one can help you picture the path from “hit send” to arrival: The journey of a SWIFT payment.

In addition, SWIFT’s migration matters for automation. When message fields become structured, banks can process faster and reduce manual reconciliation. That’s one reason the ISO 20022 change keeps showing up in wire discussions.

Still, correspondent banking can create timing gaps. If a correspondent bank is closed, the message may sit until the next processing window.

Europe’s SEPA and Emerging Faster Links

Europe has its own instant euro system: SEPA Instant Credit Transfer (SCT Inst). It’s designed to settle in 10 seconds or less and works 24/7 within the SEPA zone.

If you’re sending euros inside SEPA, you get a different user experience than most global wires. The message is routed through a regional infrastructure made for speed.

And because SEPA is part of broader global payment routes, faster European settlement can reduce the “final-mile” wait for many international flows.

At the global level, real-time payments are growing across more than 80 countries, but not every corridor supports true instant delivery. Many places offer real-time systems, while other corridors rely on near-real-time updates or faster tracking layers like SWIFT gpi.

So the practical takeaway is this: you may see “instant” in one country and “overnight” elsewhere, even when the messaging is modern.

Security Measures and 2026 Innovations

Payments live in a world with constant fraud attempts. So the communication chain includes multiple protection layers, not just one.

When banks exchange payment messages, they often combine:

  • Encryption for in-transit data security
  • Verification rules for account and payment details
  • Monitoring for suspicious patterns
  • Controls for sanctions and compliance

In 2026, two things stand out. First, instant payment growth means fraud teams work with less time to respond. Second, messaging upgrades like ISO 20022 increase the number of fields available for risk checks.

Here’s a useful way to picture security layers.

Clean modern illustration of three stacked security layers in payments: encrypted shield, AI alert icon, and bank vault lock, using blue-green palette with subtle gray-to-white gradient background.

Meanwhile, banks increasingly use AI-driven alerts to flag odd behavior fast. That doesn’t mean AI “solves fraud.” It means it can spot patterns earlier, then route cases to human teams when needed.

Also, real-time payment systems can support instant blocks when risk hits a threshold. If the rail and the bank’s policies allow it, the system can stop a payment before settlement.

One more trend is the rise of RFP-based flows and better wallet-to-bank interaction. As more apps connect to instant rails, users get clearer context on what they’re paying for. That can reduce mistakes, which also improves security.

Built-In Protections Every Step of the Way

Even when the payment looks simple in an app, the internal chain has guardrails.

Security usually shows up as:

  • Encryption and secure channels for message travel
  • Validation checks on routing and beneficiary data
  • Rules tied to structured data (like payment purpose)
  • Finality rules that make settled payments harder to reverse

Because the message includes clearer identifiers, banks can better link a payment to its events. If something goes wrong, investigations have a tighter trail.

Still, remember this reality:

Once funds settle, reversing a payment can be hard.
That’s why banks screen so aggressively.

So you get both speed and tradeoffs. Instant settlement can reduce waiting, but it also pushes banks to prevent fraud earlier.

Conclusion

That friend-money scenario starts with a question: what happens after you press send? The answer is communication, message formats, and settlement rules working together.

In 2026, ISO 20022 is the shared language pushing payments toward better data, faster processing, and cleaner tracking. Real-time rails like RTP and FedNow then turn that clearer messaging into seconds-level delivery. Meanwhile, SWIFT gpi and regional systems like SEPA SCT Inst show how cross-border and cross-region payments keep improving.

Next time you see an instant or a delayed transfer, check the details your app shows (status updates, references, and any reason codes). Small clues help you connect the dots between the message and the outcome.

What’s your most confusing payment story, the one that made you ask “why did that take so long?” Share it in the comments, and follow for more practical fintech explainers.

Leave a Comment