Push and Pull: The Two Directions Money Moves
Part III · Bank Account Rails (Chapters 9–12) Builds on: Chapter 2 (clearing and settlement, netting, finality), Chapter 8 (the scenarios cards can't cover) New concepts in this chapter: push and pull, direct debit, the debit mandate, the return window, ACH
This chapter draws the topmost dividing line of the entire course. Every rail and every scheme that follows can be sorted against this line first.
1. The Question the Previous Chapter Left Open¶
The previous chapter closed with the card's three unchangeable properties: fees are a percentage, so large amounts cost too much; natively a pull model, so it can't pay wages; chargebacks built in, so the payee can't relax for 120 days.
The second one deserves a pause — what does "pull" mean? And why does it decide that cards can't pay wages?
2. Money moves between accounts in only two directions¶
| Direction | Who initiates | In one line | Typical scenes |
|---|---|---|---|
| Push (credit) | The payer | I send the money to you | Payroll, reimbursements, mortgage payments, cross-border remittances |
| Pull (debit) | The payee | Using the authorization you gave me, I go take it from your account | Card purchases, utility auto-debits, subscription charges |
Note that push and pull are about who initiates — not which way the money flows. Cards are the textbook pull, yet the funds still flow from issuer to acquirer and on to the merchant — the authorization path and the funds path run in opposite directions, plainly visible in the two counter-running chains of the diagram in the four-party model.
Pull has two instruments, and cards are only one
This is the cell most people miss:
| Instrument | What the payee pulls with | Examples |
|---|---|---|
| Cards | Card number + an authorization message | Everything in the previous five chapters |
| Direct debit from a bank account | Account number + a debit mandate | ACH debit in the US, SEPA DD in the euro area, Direct Debit in the UK |
Direct debit never touches a card; it takes straight from the bank account. Your utilities, your broadband, your gym membership — odds are they run on it, not on a card.
Which explains how this course could spend five chapters on cards and still not be done with "pull": cards are only half of it.
A conclusion you can write down now
Direct debit has one limit cards don't: it only works inside a region with one rulebook.
The US has ACH, the euro area has SEPA DD, the UK has Direct Debit — but there is no global direct debit anywhere in the world, because direct debit depends on a common mandate standard and common return rules, and neither of those crosses the edge of a currency zone.
So:
Domestic pull has two roads. Cross-border pull has exactly one left: the card networks.
That sentence returns when the course reaches cross-border — where you'll see that the world's only two channels are, neatly, one push and one pull, one cell each.
3. The danger in pull, and the line of defense that holds it¶
Pushed money leaves by your own hand; if something goes wrong, at least you were the one who pressed the button (the case where you were conned into pressing it gets its own treatment when the course reaches instant clearing). Pull is different — someone else, holding nothing but a string of digits, can take money out of my account.
Take US ACH debit. If I know your bank account number and routing number (printed along the bottom of a check, publicly discoverable), I can initiate a debit against you. Those two numbers appear on every check; they are nothing like a secret.
What stops this is not technology. It is two layers of mechanism:
| Mechanism | What it does | Its limit |
|---|---|---|
| The debit mandate | The originator must hold the payer's written or electronic authorization; pulling without one is a violation | The system itself never checks that the mandate exists — it is liability after the fact, not a gate before it |
| The return window | The payer can claw the money back afterward | This is the real line of defense — next section |
You have already met the card side's counterparts. The mandate corresponds to the 3DS and tokenization of card-not-present — verifying it's really you in the instant of the transaction, swapping the real card number for a single-purpose token: gates set before the fact. The return window corresponds to the chargeback. Same problem, two sets of answers.
4. The return window: arrival is not finality¶
Back to finality from clearing and settlement. Money that was pulled can still be sent back after it lands.
The common US ACH return codes:
| Return code | Meaning | Who initiates | Deadline |
|---|---|---|---|
| R01 | Insufficient funds | The payer's bank | 2 banking days |
| R02 | Account closed | The payer's bank | 2 banking days |
| R03 | No such account, or name doesn't match | The payer's bank | 2 banking days |
| R10 | Customer says the debit was never authorized | The consumer | 60 days from the statement date |
| R29 | Corporate customer says it was never authorized | The business | 2 banking days |
Look at the deadlines on R10 and R29 — a factor of 30 apart:
Consumer accounts get 60 days of protection. Business accounts get 2.
The logic underneath: regulation treats the consumer as the weaker party and shields them (Regulation E in the US), while a business is presumed able to watch its own account. SEPA DD in the euro area is the same idea with different numbers: consumers get a no-questions-asked refund for 8 weeks, and where the mandate doesn't hold up, disputes can reach back 13 months.
Drawn to scale in calendar days, that 30x looks like this:
For the entire length of the long bar, the money you received is not final.
What this means if you build products:
| Scenario | Risk |
|---|---|
| You pull from consumer accounts | For 60 days, the payer can say "I never authorized this" at any moment, and the money is pulled back out |
| You push to consumer accounts | Comparatively safe |
| You pull from business accounts | Only a 2-day window; far less risk |
The rolling reserve from the card transaction lifecycle — the acquirer withholding a slice of every settlement for a while — how long it withholds is set by exactly this table.
Put chargebacks and returns side by side and the pattern falls out:
Every pull must leave the payer a window to change their mind. The money was taken from their account by someone else; without that window, nobody would dare use the system. And that window is precisely the payee's risk exposure.
5. The push side: why nothing replaces it¶
Pull cannot do payroll. The reason is blunt: a company cannot hold mandates from 5,000 employees and go "collect" money out of their accounts for itself — the direction is simply backwards.
Payroll has to be push. And push has a completely different cost structure from pull:
A company pays 5,000 employees a total of $20 million.
On the batch net rail (ACH credit): 5,000 payments × $0.03 = $150
By wire (Fedwire): 5,000 payments × $25 = $125,000
Gap: 125,000 ÷ 150 ≈ 833x — close to three orders of magnitude
Cross-check: the wire bill already exceeds 0.6% of total payroll, while batch netting costs 0.00075%. This is why payroll everywhere in the world runs on batch net rails. No exceptions.
Batch net rails are slow because they copied the playbook from clearing and settlement wholesale: accumulate a batch, compute the net, settle at end of day. No single step in the chain needs a day; every step just waits for the next batch window.
(Same Day ACH, rolled out in the US from 2016, packs the windows closer together; it does not make the system faster — at heart it is still batch accumulation. So it still has cutoff times, gaps between windows, and no service on weekends or bank holidays.)
6. Pull's other gap: no checking the balance in advance¶
The same $100 collection, card versus direct debit:
| Dimension | Card | Direct debit |
|---|---|---|
| Cost | A percentage, commonly 2–3% | Per item, a few cents to a few tens of cents |
| Worth it at size? | No — the bigger the amount, the more it costs | Yes — cost is independent of amount |
| Speed | Authorization in seconds; funds at T+1 to T+2 | 1 to 3 business days |
| Payee's certainty | Outcome known at authorization, but chargebacks possible for 120 days | No idea in advance whether the money is there; returns possible for 60 days |
| Can it verify the balance beforehand? | Yes — the issuer checks at authorization | No |
The last row is direct debit's biggest soft spot.
It has no real-time authorization step the way cards do. (Keep the two apart: the debit mandate from earlier is permission the payer granted in advance — a contract. This is the card's real-time check, the instant question to the issuer: "can this card take this charge?" Direct debit has the former and lacks the latter.)
You submit a debit instruction and the system tells you nothing about whether the money is there — you wait a day or two, and maybe an R01 (insufficient funds) return comes back.
This directly spawned an industry: account balance verification services (one of the businesses companies like Plaid were built on) — confirming by some other route that the money is in the account before you fire the debit.
A defect in an infrastructure grows a whole layer of business on top of it.
You will see this pattern several more times.
7. The Question This Chapter Leaves Open¶
The push–pull line is now drawn; every rail from here on gets sorted against it first.
But the push side still has one unsolved problem: batch netting is cheap and handles size, but it is slow (measured in days) and not final (nothing counts until the return window closes).
Some scenarios can tolerate neither. A home purchase must confirm receipt on closing day, with zero possibility of a return; a payment between companies in the tens of millions cannot wait three days.
These call for a rail that is fast and irrevocable at once. The US has three, each with its own origin story. The next chapter puts them side by side in one table.
8. Self-check questions¶
- State the difference between push and pull in one sentence. Why are cards "natively pull"?
- You are building a subscription product for US consumers, collecting by direct debit. Name the number your product design must hold risk exposure open for, and why.
- Why is cross-border pull down to the card networks alone, when domestic pull has two roads?
9. Answers¶
Answer for yourself before reading on.
The difference is who initiates, not which way the money flows. Push: the payer sends the money out. Pull: the payee, holding an authorization, goes and takes it from the payer's account. Cards are natively pull because the whole flow starts on the merchant's side: the merchant takes the card number to the issuer and asks "can I charge this?" — the debit instruction comes from the payee. Which is also why cards can't pay wages — payroll needs the payer to push to thousands of people at once, and the direction is backwards.
60 days. A consumer can send back a debit that already landed, on grounds of "not authorized," for 60 days from the statement date. That means your revenue is not final for 60 days — so the product either carries enough bad-debt provision, or keeps mandate evidence ready to contest disputes, or delays shipping and activation for high-risk users.
Because pull's two instruments do not travel equally. Direct debit depends on a common mandate standard and common return rules, and those grow up together with a currency zone — the US's ACH, the euro area's SEPA DD, the UK's Direct Debit are each their own, mutually incompatible, and no global version exists.
The card networks took the other road: instead of unifying every country's rules, they wrote one rulebook of their own and outsourced issuing and acquiring to local banks in each country. That way no country has to change its own clearing system, yet the card works worldwide. The price is percentage-based fees — a bad deal at size.
Previous: Chapter 8 · Card Not Present: A Thirty-Year Fraud Arms Race Next: Chapter 10 · The Four US Rails, Side by Side