If you can really perform one using your account and routing number, it might also be RTP.
From "FedNow FAQ" https://news.ycombinator.com/item?id=32515531 :
> W3C ILP Interledger Protocol [1] specifies addresses [2]: [...]
>> Neighborhoods are leading segments with no specific meaning, whose purpose is to help route to the right area. At this time, there is no official list of neighborhoods, but the following list of examples should illustrate what might constitute a neighborhood:
>> - crypto. for ledgers related to decentralized crypto-currencies such as Bitcoin, Ethereum, or XRP.
>> - sepa. for ledgers in the Single Euro Payments Area.
>> - dev. for Interledger Protocol development and early adopters
> From "ILP Addresses - v2.0.0" [2]:
>> Example Global Allocation Scheme Addresses
>> - g.acme.bob - a destination address to the account "bob" held with the connector "acme"
>> - g.us-fed.ach.0.acmebank.swx0a0.acmecorp.sales.199.~ipr.cdfa5e16-e759-4ba3-88f6-8b9dc83c1868.2 - destination address for a particular invoice, which can break down as follows:
>> -- Neighborhoods: us-fed., ach., 0.
>> -- Account identifiers: acmebank., swx0a0., acmecorp., sales, 199 (An ACME Corp sales account at ACME Bank)
>> -- Interactions: ~ipr, cdfa5e16-e759-4ba3-88f6-8b9dc83c1868, 2*
> And from [3] "Payment Pointers and Payment Setup Protocols":
>> The following payment pointers resolve to the specified endpoint URLS:
$example.com -> https://example.com/.well-known/pay
$example.com/invoices/12345 -> https://example.com/invoices/12345
$bob.example.com -> https://bob.example.com/.well-known/pay
$example.com/bob -> https://example.com/bob
> The WebMonetization spec [4] and docs [5] specifies the `monetization` <meta> tag for indicating where supporting browsers can send payments and micropayments: <meta
name="monetization"
content="$wallet.example.com/alice">
ILP also specifies settlement; From "Fed expects to launch long-awaited Faster Payments System by 2023" (2022) https://news.ycombinator.com/item?id=32658402 :> And then you realize you're sharing payment address information over a different but comparably-unsecured channel in a non-stanfardized way; From https://github.com/interledger/rfcs/blob/master/0009-simple-... :
>> Relation to Other Protocols: SPSP is used for exchanging connection information before an ILP payment or data transfer is initiated
> To do a complete business process, [there's] signaling around transactions, which then necessarily depend upon another - hopefully also cryptographically-secured and HA Highly Available - information system with API version(s) and database schema(s) unless there's something like Interledger SPSP Simple Payment Setup Protocol and Payment Pointers [...]
Clearing (finance) > US: https://en.wikipedia.org/wiki/Clearing_(finance)#United_Stat...
ACH Network: https://en.wikipedia.org/wiki/ACH_Network :
> The Federal Reserve's FedACH and The Clearing House Payments Company's Electronic Payments Network (EPN) are the two ACH operators in the United States.[3]
From https://news.ycombinator.com/item?id=28232243 :
> FWIU, each trusted ACH (US 'Direct Deposit') party has a (one) GPG key that they use to sign transaction documents sent over now (S)FTP on scout's honor - on behalf of all of their customers' accounts.
Payment rail: https://en.wikipedia.org/wiki/Payment_rail
EFT: Electronic Funds Transfer: https://en.wikipedia.org/wiki/Electronic_funds_transfer
From "Ask HN: What security is in place for bank-to-bank EFT?" (2021) : https://news.ycombinator.com/item?id=26111184 :
> AFAIU, no existing banking transaction systems require the receiver to confirm in order to receive a funds transfer. [...]
> ILP: Interledger Protocol > RFC 32 > "Peering, Clearing and Settling" describes how ~EFT with Interledger works: https://interledger.org/rfcs/0032-peering-clearing-settlemen...
Why do we have such a slow, fragmented, unsecured system(s) for banking and finance?
What are the solutions; how do we unify and eliminate waste?
There's no such mechanism that I'm aware of, though – instead instant deposits usually use debit card rails.
The receiving bank doesn’t bear any risk, Venmo is taking the risk.
You are the person who is the beneficiary on the accounts this money sits on. So you are responsible for it. If an entity sends money on your behalf, they take the responsibility for the money you send. That means they are the ones with the processes that will trigger if money doesn’t clear as expected. Processes which may involve anything from reminder emails and push notifications, all the way to debt recovery companies, lawyers and thugs showing up at your door.
Both entities have float. The question is who is taking legal risk.
What risk? Venmo is the sender here. Almost by definition, the sender doesn't have any risk: They either send money they have (in which case all is well), or promise to send money they don't have (which is the recipient's problem).
If you're talking about the transaction that originally funded the to-be-paid-out balance, that's a completely different story.
> Venmo is sending money from Venmo bank accounts to your bank, through a direct integration.
Yes, and that "direct" integration is typically ACH (for transfers "in 3-5 days") or debit card rails (for "instant payouts"). It might also be RTP these days, and maybe soon will be FedNow, which are both cheaper than debit card push payments (although I don't see payment app providers stopping their very lucrative business of charging ~1% for instant payouts any time soon).
For ACH, there is no risk to the recipient. since nobody is floating anything: It takes 3-5 days. For debit cards, there is also no risk since these payments are effectively final immediately after they're announced to the recipient, even though they don't settle instantly.
No, they have the money. But the money is ultimately that of the Venmo user. If that money gets removed from the account by some other means (eg some form of clawback, dispute, whatever) then they're out that user's money, and they're on the hook: So Venmo pays for the user.
Every dollar is somebody else's dollar.
Sure, but that's completely independent of the finality, settlement timing, payment rails etc. of the payout side.
So if you're talking about the funding side, ACH is indeed very risky, since it's ACH direct debit. But great-GP was talking about Venmo payouts. There, Venmo is an ACH credit sender, which is risk-free.
A lot of apps like CashApp, Venmo, Uber Driver, Lyft Driver, etc give you two options for getting your money out of their app. Instant and Delayed. Delayed is usually free and deposits into a linked bank via ACH. Instant is immediate and is a reverse transaction on a linked debit card.
This is RTP and it usually isn't free.
People outside banks often find this surprising.
In ACH, as soon as you get the notification about an inbound credit transfer, it's effectively final. Whether it ultimately settles on the same day or 1-2 days later is irrelevant, since what matters is finality.
ACH credit transfer clawbacks are very rare compared to ACH debit rejections (due to e.g. insufficient funds or fraud).