Mass payouts scale on vetting, not volume
The binding constraint on paying thousands of sellers or contractors across borders is not the transfer. It is that every recipient is a counterparty someone must verify, screen, and validate before the first payment — and when each platform runs that work alone, recipient ten thousand costs as much to vet as recipient one. A network that shares vetting is what changes the economics of mass payouts.
Payout runs break at the recipient layer
The transfer is the part everyone optimizes and the part that was never the problem. A payout run is not one payment; it is thousands of counterparty relationships compressed into a file. Before the first instruction can execute, every row in that file has to clear three gates: onboarding — establishing who the recipient is, whether an individual contractor or a company with owners behind it; screening — checking the recipient, and the people behind it, against sanctions lists before any funds move; and account validation — confirming the destination can actually receive the payment, on the right rail, in the right currency.
Each gate is compliance work someone has to do, and today that someone is you, for every recipient, from scratch. A seller already vetted by three other marketplaces still starts at zero on yours — the work does not carry. That is why new sellers wait weeks for a first payout while the review queue clears, and why the queue itself becomes the cap on how fast the platform can add recipients at all.
The standard fix multiplies the problem instead of solving it. A payout provider per region means a vetting process per region: different document requirements, different review queues, different definitions of "verified." The recipient layer fragments exactly as it scales.
Per-platform vetting makes recipient ten thousand as expensive as recipient one.
The batch problem
Payout runs also have awkward review geometry. The file is one object; the risk is per recipient. Run review at the level of the file and a single flagged recipient stalls thousands of clean payments behind it — operations pulls the batch, splits it, resubmits, and every recipient in the run inherits the delay caused by one.
The unit of review has to be the instruction, not the batch. Screening runs against each payment individually; a flag holds that one instruction and routes it to a human analyst; the rest of the run settles on schedule. The flagged case gets the attention it deserves without taking hostages.
What makes per-instruction review affordable at scale is sequencing: the expensive work — vetting the counterparty — happened at onboarding, so what runs at payment time is a check against a recipient already known. Screening a vetted recipient is fast. Vetting a recipient at run time is what turns a payday into a queue.
What stablecoin rails change
The money leg does improve, and the improvement is real. A batch run against banking-hours rails inherits every cutoff in the chain: miss the window and the run waits a day; cross a border and it waits on correspondent hops and time zones. A stablecoin transfer is final on-chain in minutes, at any hour of any day. A payout run released on Friday evening settles Friday evening — the payout calendar becomes the platform's product decision instead of the rail's operating schedule. Where recipients want local currency, the last leg pays out over local rails; it is the cross-border leg, the one that used to carry the delay, that stops waiting.
But faster settlement makes the recipient-layer problem more visible, not smaller. A rail that settles in minutes behind an onboarding process measured in weeks has just moved the queue — the seller still waits, only now entirely on compliance. Speed on the money leg raises the question it cannot answer: why does the compliance leg still scale linearly with every recipient?
What shared vetting changes
A compliance network changes whose work the vetting is. On Infinite (infinite.net), a recipient is vetted once, to the network's standard, and that verification carries to every participant — the argument the compliance network thesis makes in full. First-time review on the network runs one to two days instead of roughly thirty, and a recipient already on the network does not restart it: they arrive vetted.
That flips the cost curve mass payouts have been stuck with. The marginal recipient stops costing a full review and starts costing what it should — a screening check at payment time. And the effect compounds across the network: every platform that joins expands the set of pre-vetted recipients available to every other participant, so the roster each platform can pay grows faster than the work any one of them puts in.
Sharing the vetting does not thin it. Screening still runs before every instruction, on every rail; monitoring runs on every transfer; a flagged case is decided by a human working from a documented file. The network removes the repetition — the same seller re-vetted platform after platform — not the review.
Platforms compete on how it feels to get paid — how fast the first payout arrives, whether payday holds on a weekend, whether one flagged account delays everyone else's. All three are recipient-layer properties. The payout file was never the product. The vetted recipient roster is.
Frequently asked questions
Why do mass payout costs scale with the number of recipients?
Because each recipient is a counterparty that must be onboarded, screened, and validated before it can be paid, and per-platform vetting repeats that work for every recipient from scratch. The transfer is a small share of the cost. Shared vetting flattens the curve: a recipient already verified on the network arrives vetted.
Can one flagged recipient hold up an entire payout run?
Only when review runs at the batch level. When screening runs per instruction, a flag holds that single payment for human review while the rest of the run settles on schedule. See how a payout run executes on Infinite, corridor by corridor.
Do stablecoin payouts settle outside banking hours?
Yes. A stablecoin transfer is final on-chain in minutes, at any hour of any day, so a payout run has no cutoff window to catch. Where recipients take local currency, the final leg pays out over local rails on their schedules — it is the cross-border leg that stops waiting.