Chapter 18 — Bank Transfers, RTPs & Virtual Accounts

It's Monday morning at MakanKaki, a food delivery platform connecting hawkers across Singapore with hungry customers. Priya, the ops manager, opens the reconciliation dashboard and feels her stomach drop. There are 847 unmatched bank transfers from Friday's hawker settlements. Three are partial payments — someone sent $47.50 instead of $48.00. One is a duplicate. And her phone is buzzing: Uncle Tan, who runs a chicken rice stall in Toa Payoh, wants to know where his $2,340 payout went.

Where did the money go?

If you've been reading this book from the beginning, that question should sound familiar. We asked it in Chapter 4 when you tapped your card for coffee. But back then, the card network — Visa, Mastercard — acted as a central nervous system. It routed the message, confirmed the authorization, tracked the clearing, and made sure settlement happened. Every participant spoke the same protocol.

Bank transfers have no such luxury. When a customer pays MakanKaki via PayNow, or when MakanKaki settles a hawker via bank transfer, the money moves on a fundamentally different kind of rail — one where there's no card network sitting in the middle, no universal dispute process, and no standardized message format tying every transaction to an invoice number.

To understand why Priya's Monday looks like this — and how to fix it — you need to understand the rails beneath your banking app. That starts with the most fundamental question in account-to-account (A2A) payments: who initiates the money movement?

Push vs. pull: the first decision that shapes everything

Every bank transfer boils down to a simple question: does the person sending the money initiate the transaction, or does the person receiving it?

In a push payment (technically called a credit transfer), you — the payer — tell your bank to send money to someone. You open your banking app, enter the recipient's details, authenticate, and press "Send." The money moves because you pushed it.

In a pull payment (technically called a direct debit), the payee initiates the movement. Your landlord, your utility company, or your gym submits a collection request to their bank, and their bank reaches into your account and takes the money — because you previously gave permission through a document called a mandate.

Here's what's remarkable: almost every real-time payment (RTP) system in the world is push-based. PayNow in Singapore, PromptPay in Thailand, Unified Payments Interface (UPI) in India, Pix in Brazil, FedNow in the US — they're all built around credit transfers initiated by the payer. The BIS Committee on Payments and Market Infrastructures (CPMI), which studies these systems globally, explicitly notes that most fast payment implementations are based on push transactions.

Why? Because push aligns naturally with two things that matter enormously when money moves in seconds: authentication and finality. When you push money, you authenticate yourself before the transfer. The bank knows it's you. When someone pulls money from your account, the authentication happened earlier (when you signed the mandate), and there's always a question of whether that permission is still valid, whether the amount is correct, and whether you actually agreed to this particular debit.

But pull payments aren't going away. They're essential for recurring collections — your rent, your insurance premium, your subscription fees. We'll explore mandates and direct debits deeply in Chapter 20. For now, the key point is that most of the real-time rails you'll encounter as a merchant or product builder are push rails, and that shapes everything from fraud risk to user experience.

There's a clever bridge between push and pull called request-to-pay (RtP). It works like this: the payee sends you a structured payment request — essentially a digital invoice with all the details pre-filled. You review it in your banking app and tap "Approve." That approval triggers a push credit transfer. The payee gets the "pull-like" experience of initiating the billing cycle, but the actual money movement is a push, with all the authentication and finality benefits that come with it. The European Payments Council has formalized this as SEPA Request-to-Pay, and ISO 20022 defines a specific message type (pain.013) for it.

For MakanKaki, this matters directly. Customer payments work great as push: a customer opens the app, sees their $12.50 order total, taps "Pay with PayNow," and pushes the money. But for premium hawker subscriptions (a monthly platform fee), MakanKaki would love to pull the fee automatically — which means either using a direct debit mandate or implementing request-to-pay to prompt the hawker to approve each month.

The fraud profiles of push and pull are almost mirror images. Push payments are vulnerable to authorized push payment (APP) scams — where a fraudster tricks you into voluntarily sending money to the wrong account. The UK's Payment Systems Regulator defines these as cases where a consumer is deceived into sending a payment to a fraudster posing as a genuine payee. Because the transfer is instant and final, recovering the funds is extremely difficult.

Pull payments invert the risk: the main danger is unauthorized debits — a payee submitting a collection without proper consent, or for the wrong amount. But pull systems have built-in dispute windows (you can reverse a direct debit within a defined period), which makes recovery easier at the cost of adding uncertainty for the payee.

How real-time payments actually work

Let's follow MakanKaki customer Wei Lin as she orders chicken rice. She opens the app, confirms her $12.50 order, and taps "Pay with PayNow." Here's what happens in approximately three seconds.

First, Wei Lin authenticates in her banking app (face ID, fingerprint, PIN — whatever her bank requires). Her bank — the payer's payment service provider (PSP) — creates a payment instruction: "Send $12.50 to MakanKaki's PayNow-linked account."

Second, her bank submits this instruction to the instant payment system — the central switch that routes real-time payments. In Singapore, this is the FAST (Fast and Secure Transfers) infrastructure. The switch validates the message, checks that the recipient exists, and forwards it to MakanKaki's bank — the payee's PSP.

Third, MakanKaki's bank credits MakanKaki's account with $12.50 and sends a confirmation back through the switch. Wei Lin's app shows "Payment successful." MakanKaki's system marks the order as paid. The hawker gets a notification to start cooking.

Three seconds. Done. But here's where it gets interesting — and where many product builders get tripped up.

"Instant to the user" doesn't always mean "instant settlement between banks"

Wei Lin sees her money leave. MakanKaki sees the money arrive. But between the two banks, the actual settlement — the final, irrevocable transfer of central bank money that extinguishes the obligation between them — may not have happened yet.

The CPMI explicitly distinguishes between two things: the rapid availability of final funds to the payee, and the timing of clearing and settlement between PSPs. In many RTP systems, the payee's bank credits the payee before interbank settlement occurs. This is called deferred net settlement (DNS) — the banks tally up all the payments between them during a window and settle the net amount later (often multiple times per day, sometimes only once).

Think of it like this: imagine you and a friend buy each other coffee throughout the week. Rather than exchanging cash each time, you keep a running tab and settle up on Friday. Each individual coffee is "paid for" immediately in terms of your agreement, but the actual cash movement is deferred and netted.

This design works, but it creates a subtle risk. From the moment MakanKaki's bank credits MakanKaki's account until the moment interbank settlement actually happens, MakanKaki's bank is fronting the money. If Wei Lin's bank failed before settlement, MakanKaki's bank would bear the exposure. The CPMI flags precisely this credit exposure as a core risk channel in fast payment deployments.

The alternative is real-time gross settlement (RTGS), where each payment settles individually and immediately in central bank money. This eliminates credit exposure but requires banks to maintain large liquidity buffers, since they can't net offsetting payments.

Most modern RTP systems use some hybrid: immediate crediting to payees with frequent (but not per-transaction) settlement cycles between banks, sometimes with risk controls like pre-funded positions or collateral requirements.

The messaging backbone: ISO 20022

If you're building on these rails, you'll encounter ISO 20022 — the messaging standard that's gradually becoming the common language of payments. Unlike older formats (like ISO 8583 for cards, or proprietary bank messaging), ISO 20022 carries rich, structured data: not just "$12.50 from A to B" but detailed remittance information, purpose codes, and compliance metadata.

Where it's adopted, ISO 20022 makes reconciliation dramatically easier because the payment message itself can carry structured invoice references. Where it's not adopted — and many systems still use proprietary messaging — reconciliation falls back to free-text fields, QR payload conventions, or hacks like virtual account numbers. We'll see this divergence play out across the global landscape shortly.

The scale is staggering

Real-time payments aren't a niche experiment. According to the ACI/GlobalData "Prime Time for Real-Time" benchmark, global real-time payment transactions reached 266.2 billion in 2023 — growing 42.2% year-over-year — and are forecast to hit 575.1 billion by 2028.

The heavyweights tell the story. India's UPI processed 228.3 billion transactions in 2025 alone, representing roughly 49% of all real-time payment volume globally and capturing 84.8% of India's retail digital payments. Brazil's Pix handled approximately 64 billion transactions in 2024 — about five times the combined volume of the country's debit and credit card payments. "Send a Pix" has become a common expression in Brazilian Portuguese.

In Europe, the EU's Instant Payments Regulation mandated that all eurozone banks must support SEPA Instant Credit Transfers (SCT Inst) for sending by October 2025, with processing completed within nine seconds. The European Central Bank reported that daily instant payment volumes rose 72% in 2024 compared to 2023.

The United States is the notable laggard. FedNow launched in July 2023 and had approximately 1,400 financial institutions onboard by mid-2025 — impressive growth, but still processing only a tiny fraction of US payments. The Clearing House's RTP network, launched in 2017, reaches about 70% of US demand deposit accounts but volumes remain small relative to ACH and cards.

The message is clear: outside the US, real-time payments are rapidly becoming the default way money moves between bank accounts.

Virtual accounts: the reconciliation primitive

Remember Priya's 847 unmatched transfers? Let's understand why that happened.

When MakanKaki first launched, they gave hawkers a simple instruction: "Transfer your platform fee to our DBS current account 001-234567-8, and put your hawker ID in the reference field." Straightforward, right?

Except Uncle Tan types "chicken rice Toa Payoh" in the reference field. Auntie Mei puts "Dec payment." One hawker uses their phone number. Another leaves the field blank entirely. And when the bank statement arrives, MakanKaki's finance team sees 847 credits to account 001-234567-8 with free-text references that are truncated, misspelled, inconsistent, or missing.

This is the fundamental problem that virtual accounts (VAs) solve.

A VA is not really an "account" in the traditional sense. Your money doesn't sit in a separate vault. Instead, it's a bank-issued account number that maps back to a single master account — but because the number itself is unique and structured, it tells you exactly who paid and (optionally) what they paid for, without relying on free-text references.

Think of it as giving every hawker their own unique "mailbox number" at the same physical address. All the mail (money) arrives at one building (the master account), but because each letter is addressed to a specific mailbox, you instantly know who it belongs to.

Banks describe this precisely. ANZ defines virtual accounts as a structure allowing clients to segregate balance and transaction information under a single physical account, with each virtual account identified by a unique number used for tracking, reporting, and reconciliation. DBS Singapore positions VAs as a receivables reconciliation accelerator — you assign each payer a unique VA, receive payments to that VA, and the bank credits your linked current account while providing transaction reports that map directly to your enterprise resource planning (ERP) system.

In Southeast Asian regulatory vocabulary, the concept takes a slightly different framing. Bank Indonesia's Payment Systems Blueprint 2025 describes a virtual account as an identification-number-based service designed to identify receipts and disbursements to and from an account.

But regardless of how it's described, the operational primitive is the same: a VA number is a deterministic key that collapses "who paid?" and "what is this for?" into the routing identifier itself. Under the hood, MakanKaki's system maintains a mapping table:

va_number → (hawker_id, expected_amount, expiry, status)

When a payment arrives at VA number 8801-0042-7731, MakanKaki's system doesn't need to parse free-text — it looks up the VA, finds it belongs to Uncle Tan (hawker #42), automatically posts the accounting entry, and updates Uncle Tan's settlement dashboard. Straight-through processing, zero manual matching.

The benefits are immediate: reduced unreconciled receipts, faster credit-limit releases (if you know exactly who paid, you can extend more credit to them sooner), and direct ERP upload for accounting teams who would otherwise spend hours matching bank lines to invoices.

But VAs come with real costs. First, they introduce statefulness — every VA number must be issued, tracked, potentially expired, and carefully recycled. You can't just assign numbers randomly; you need to prevent enumeration attacks (where someone systematically guesses VA numbers to probe your customer base). Cross-border proxy lookup systems explicitly include safeguards against this kind of data mining, like masking recipient names and restricting lookup frequency.

Second, VAs create portability constraints. If MakanKaki's VA namespace is bank-specific (say, all their VAs start with "8801" because DBS assigned that prefix), switching banks means reissuing every VA number and updating every hawker's payment instructions. This lock-in is a real cost, especially for fast-growing companies that may want to negotiate better banking terms.

Third, VAs sometimes work around problems that better standardization could solve directly. If every payment carried structured remittance data via ISO 20022, you might not need VAs for reconciliation at all — the payment message itself would tell you everything. The G20's cross-border payments roadmap explicitly identifies harmonized ISO 20022 as a building block for reducing exactly this kind of friction.

Static vs. dynamic virtual accounts

Not all VAs work the same way. The key distinction is how tightly the VA identifier binds to a specific payment intent.

A static VA binds to an identity — typically a customer or business relationship. MakanKaki might assign each hawker a permanent VA: Uncle Tan is always VA 8801-0042-7731. He uses the same number every time he receives a settlement. It never expires. It's like a permanent mailbox.

A dynamic VA binds to a specific transaction or invoice. When a customer places a $12.50 order, MakanKaki generates a unique VA just for that order — say, VA 8801-9988-3344 — with an expected amount of $12.50 and an expiry of 24 hours. If the customer doesn't pay within the window, the VA deactivates. If someone sends the wrong amount, the system can flag it immediately.

Payment gateway documentation makes the distinction concrete: Xendit, for example, distinguishes "invoice VA" (default expiry 24 hours) from "fixed virtual account" (effectively non-expiring for most purposes). The API surface typically exposes parameters like expected_amount, expiry_minutes, and is_single_use.

In practice, many systems blend both approaches. Banks support hierarchical structures where a static VA identifies the counterparty while a "context ID" sub-field carries the invoice reference — effectively a hybrid that gives you counterparty-level stability with invoice-level granularity.

For MakanKaki, the choice maps neatly to their two-sided model. On the settlement side (paying hawkers), static VAs work well: each hawker has one VA, and MakanKaki credits it daily. On the collection side (receiving customer payments), dynamic VAs are better: each order gets a unique VA with the exact amount and a tight expiry, so reconciliation is deterministic and stale orders auto-expire.

The global RTP landscape: a region-by-region tour

When MakanKaki's CEO decides to expand beyond Singapore — into Kuala Lumpur, Bangkok, and Jakarta — the payments team discovers something sobering: every country has its own RTP system, its own conventions, its own quirks. Here's the landscape they'll navigate.

Southeast Asia

Singapore was an early mover. FAST launched in 2014, enabling near-instant interbank transfers. PayNow, launched in 2017, added a proxy layer on top — you can send money using a phone number or national ID instead of a bank account number. The ACI benchmark reports 388 million real-time transactions in 2023, forecast to reach 717 million by 2028. Singapore's scheme messaging uses ISO 20022.

Malaysia's DuitNow, running on PayNet's infrastructure, recorded 1.87 billion real-time transactions in 2023 with a forecast of 3.23 billion by 2028. PayNet's migration to ISO 20022 was remarkably fast — all 36 banks onboarded in nine months. QR acceptance has scaled rapidly: the Association of Banks in Malaysia reports 2.6 million registered DuitNow QR merchants, with QR transactions more than doubling to 870 million in 2024.

Thailand's PromptPay is a volume monster. Bank of Thailand data for November 2025 shows approximately 2.37 billion transactions in a single month, worth THB 4,371 billion. The ACI benchmark counted 20.4 billion real-time transactions across 2023. Interestingly, PromptPay's scheme messaging is proprietary — yet it achieves enormous scale and broad QR integration without ISO 20022.

Indonesia took a different approach. Rather than building a traditional RTP rail first, Bank Indonesia launched QRIS (Quick Response Code Indonesian Standard) — a universal QR code standard based on EMVCo specifications — in August 2019, mandating nationwide implementation from January 2020. By December 2024, QRIS had 55 million users and 35 million merchants. QRIS isn't an ISO 20022 transfer scheme; it's a QR acceptance standard that rides on underlying settlement rails.

The global heavyweights

India's UPI is in a class of its own. Launched in 2016 by the National Payments Corporation of India (NPCI), UPI processed 228.3 billion transactions in 2025 — up from 172.2 billion in 2024. That's roughly 700 million transactions per day. UPI now captures 84.8% of India's retail digital payment volume. The IMF has recognized it as the world's largest retail fast payment system. The average transaction size has been falling — down to about ₹1,293 ($15) — signaling that UPI is increasingly used for small, everyday purchases at tea stalls and grocery shops.

Brazil's Pix, launched in November 2020 by the Central Bank of Brazil, processed approximately 64 billion transactions in 2024. It has roughly 170 million users and 570 million registered Pix keys (user-linked identifiers like phone numbers or tax IDs). Within Brazil, Pix is now the single most-used payment method — accounting for nearly half of all transactions in the country, per the Central Bank of Brazil — and "send a Pix" has entered the Brazilian vocabulary the way "Google it" entered English.

The West

Europe's SCT Inst scheme became operational in November 2017. But adoption was uneven until the EU's Instant Payments Regulation, which entered force in April 2024, mandated that all eurozone banks support instant payments for receiving by January 2025 and for sending by October 2025. Processing must complete within nine seconds. The ECB reported a 72% increase in daily instant payment volumes in 2024. The maximum transaction amount has been raised to a theoretical €999,999,999.99.

The United States remains the outlier. The Clearing House launched its RTP network in 2017, and the Federal Reserve launched FedNow in July 2023. By mid-2025, approximately 1,400 institutions had joined FedNow — mostly small and mid-size banks and credit unions. RTP has over 1,000 participants, primarily larger banks. Both use ISO 20022. But real-time payments remain a tiny fraction of US payment volume, which cards, ACH, and wire transfers still dominate. The US is moving from batch-world to real-time-world, but slowly.

ASEAN cross-border interoperability: corridors, not a network

Here's the question MakanKaki's CEO really wants answered: can a Thai tourist visiting Singapore pay for chicken rice using PromptPay?

The answer is yes — but not because there's a single ASEAN payment network. Instead, Southeast Asian countries have been building bilateral corridors: dedicated gateways that connect two specific RTP systems, one pair at a time.

The milestone timeline tells the story. In April 2021, the Monetary Authority of Singapore (MAS) and the Bank of Thailand (BOT) launched the PromptPay–PayNow cross-border linkage — one of the world's first live connections between two domestic instant payment systems. Transfers complete within minutes using mobile phone numbers, with a daily cap of S$1,000 or THB 25,000.

In March 2023, NETS QR (Singapore) and DuitNow QR (Malaysia) launched a cross-border QR linkage, allowing travelers to scan and pay across borders. In November 2023, PayNow and DuitNow went live with account-to-account transfers (not just QR), with a Singapore-side daily cap of S$1,000.

Indonesia has been active too. Bank Indonesia and Bank Negara Malaysia (BNM) launched a QRIS–DuitNow QR pilot in January 2022 and a commercial linkage in May 2023. In November 2023, QRIS and NETS QR connected Indonesia and Singapore.

These linkages operate through separate, dedicated cross-border gateways — bank FAQs explicitly note that cross-border connectivity uses distinct infrastructure to avoid misrouting with domestic transfers. This is a controlled corridor architecture, not a single shared switching domain.

The ASEAN-5 nations (Indonesia, Malaysia, Philippines, Singapore, Thailand) signed a Regional Payment Connectivity MoU in November 2022, and the initiative has since expanded to more ASEAN members. Ongoing efforts focus on harmonizing proxy identifiers and adopting ISO 20022 for cross-border messages.

But the most ambitious project comes from outside ASEAN proper. The BIS's Project Nexus is designed to connect domestic instant payment systems through a standardized multilateral platform — think of it as a "hub" that connects domestic RTP spokes, rather than requiring every country to build bilateral links with every other country. The Nexus blueprint was published in July 2024, and the initial participating jurisdictions include India, Malaysia, Thailand, Singapore, and the Philippines, with Indonesia as an observer. Public statements target a first-wave launch in 2026–2027.

If Nexus succeeds, it could fundamentally change the economics of cross-border instant payments. Instead of N×(N-1)/2 bilateral connections for N countries, you'd need just N connections to a central platform. That's the difference between building 10 bridges (bilateral) and building five on-ramps to a highway (multilateral).

Who built these rails: the Vocalink story

The next time you use PayNow in Singapore or PromptPay in Thailand, consider this: the infrastructure humming underneath was partly built by a company most people have never heard of — Vocalink, now a Mastercard subsidiary.

Mastercard announced its acquisition of a controlling stake in Vocalink Holdings in July 2016. This wasn't a consumer-facing play — it was an infrastructure play. Vocalink had deep expertise in real-time payment switching, having built the UK's Faster Payments system. Mastercard's case studies explicitly state that Vocalink helped Singapore's payments industry implement immediate bank transfers as part of FAST, and that PromptPay was developed by Thai banks and Vocalink.

The broader pattern here is important: in most RTP deployments, scheme governance (rules, standards, oversight) is led by the central bank and banking industry, but infrastructure delivery (the actual switching technology, risk engines, and operational tooling) is often outsourced to specialized vendors. This separation of concerns — policy vs. plumbing — is a recurring architectural pattern across payments.

This matters for cross-border interoperability because corridor-based gateways require message mapping, ID translation, and real-time risk monitoring across jurisdictions. Vendors with proven RTP switching capabilities have a natural advantage supplying these components under central bank oversight.

Where this is heading: 2026 and beyond

If you've been following the news, you might wonder: will stablecoins and crypto replace all of this? Short answer: no. Longer answer: they'll integrate with it, not displace it.

Stablecoins and tokenized deposits are best understood as additional settlement instruments that can be plugged into payment flows. The IMF notes that through tokenization, stablecoins could increase payment efficiency — particularly for cross-border transactions — by reducing costs and improving speed. But the emphasis is on could, under the right conditions.

Those conditions are substantial. The Financial Stability Board (FSB) recommends that stablecoin arrangements face the same regulatory standards as equivalent traditional activities — the principle of "same activity, same risk, same regulation." The Financial Action Task Force (FATF) requires that stablecoin transfers comply with the Travel Rule, meaning originator and beneficiary information must accompany every transfer. The FSB's 2025 thematic review found that while jurisdictions are making progress on crypto-asset regulation, gaps and inconsistencies remain.

So what does the most plausible architecture look like for the next five years? Not "stablecoins replace RTPs" — but interoperability across ledger types: bank deposits, tokenized deposits, and stablecoins, connected through regulated on/off-ramps and standardized messaging. A user might pay in via a domestic RTP, the cross-border leg might settle on a stablecoin rail where it's faster and cheaper, and the recipient cashes out via their local RTP. The compliance and orchestration layers sit in between.

The BIS is actively exploring this multi-rail future. Project Agorá tests the feasibility of a multi-currency unified ledger for wholesale cross-border payments. Project Nexus connects domestic instant payment systems for retail. Together, they sketch a future where the boundaries between different settlement rails become less visible to the end user.

A conservative timeline, grounded in published standards work: in 2026–2027, expect continued corridor expansion in ASEAN RTP and QR linkages (still largely bilateral), alongside early implementations aligned to Nexus-style patterns and a gradual tightening of stablecoin rules and Travel Rule enforcement.

In 2028–2030, stablecoins are most likely to persist as a meaningful settlement option in corridors where legacy friction is highest — certain remittance and B2B routes — but mainstream adoption depends on regulatory clarity, robust reserve design, and the ability to interoperate with domestic RTP systems at scale.

The real-time payment rails aren't going away. They're becoming the foundation on which everything else — QR codes, wallets, cross-border corridors, and eventually tokenized money — is built.

In the next chapter, we'll explore the interface layer that sits on top of these rails: QR codes, proxy identifiers, and the pay-by-scan revolution that's turning every phone into a point-of-sale terminal.

Sources

• BIS Committee on Payments and Market Infrastructures (CPMI), Fast payments — Enhancing the speed and availability of retail payments (2016)
• ACI Worldwide / GlobalData, Prime Time for Real-Time 2024 benchmark report
• European Central Bank, payment scheme definitions (credit transfer, direct debit)
• European Payments Council, SEPA Instant Credit Transfer (SCT Inst) rulebook and SEPA Request-to-Pay scheme
• EU Regulation 2024/886 (Instant Payments Regulation)
• ANZ, virtual accounts product documentation
• DBS Bank (Singapore), virtual account product documentation
• Bank Indonesia, Indonesia Payment Systems Blueprint 2025
• Bank Indonesia, QRIS cross-border documentation and monthly statistics
• Bank of Thailand, PromptPay monthly transaction statistics (November 2025)
• MAS / BOT joint release, PayNow–PromptPay cross-border linkage (April 2021)
• MAS / BNM joint release, PayNow–DuitNow cross-border linkage (2023)
• Association of Banks in Malaysia, DuitNow QR adoption statistics (2024)
• NPCI, UPI product statistics (2025)
• Central Bank of Brazil, Pix transaction data (2024)
• AMRO, ASEAN Regional Payment Connectivity analysis
• Mastercard / Vocalink case studies (Singapore FAST, Thailand PromptPay)
• Financial Stability Board, high-level recommendations for global stablecoin arrangements
• FATF, guidance on virtual assets and VASPs (Travel Rule)
• BIS, Project Nexus blueprint (July 2024)
• BIS, Project Agorá documentation
• IMF, stablecoin and tokenization analysis
• Federal Reserve, FedNow service documentation
• The Clearing House, RTP network documentation
• Xendit, virtual account API documentation
• UK Payment Systems Regulator, APP scam definitions