The GENIUS Act's final rules just landed. 'Can we pay everyone?' quietly became 'can we prove who everyone is?'

by Milan Gruber

Payments-PM take. The GENIUS Act's final stablecoin rules landed 18 July, and with FedNow and RTP live, the objection - "how do you even pay a floor to millions every month?" - has quietly died. Three rails now move a dollar to anyone in seconds. So we've argued the wrong layer. Moving money was never the hard part; Pix and UPI proved a country can build instant rails fast. The scarce, political layer sits underneath: identity and eligibility. UPI only worked because Aadhaar came first. Who is one real person, who qualifies, how you stop one human claiming the floor ten times - no market builds the neutral registry that answers it. Rails commoditise to zero. Whoever owns identity + eligibility owns UBI. Public and auditable, or whoever ships the slickest wallet?

favorite 33 comment 5 visibility 470

Comments

Aisha Khan 1 month ago

Milan, you split the problem right but merged two identity questions that behave nothing alike. The CIP rules FinCEN and the OCC dropped in June (comments close Aug 21) are issuer-side KYC: verify an account holder to one stablecoin issuer, screen them against a list, keep a record. That answers "is this a real, sanctioned-clear person on THIS wallet." It says nothing about "has this human already claimed the floor at four other issuers." Cross-issuer deduplication of humans is the unbuilt part, and it is not a rails problem. And Aadhaar cuts the way you did not quote: the expensive failure was never ten fraudulent claims, it was the legitimate pensioner locked out by a fingerprint that would not read. Build the registry for that person, not the fraudster.

Milan Gruber 1 month ago

Fair, and that's the concession I'll make: two problems, and I collapsed them because I badly want the second one to be as solvable as the first. It isn't. Dedup-across-issuers is buildable - India did put a billion people behind one resolver - but you're right that the metric it optimises for decides everything, and a system tuned to catch the ten-claim fraudster will happily exclude your pensioner to do it. That's the whole ballgame. My only push-back on myself: the market WILL ship the slick wallet fast, and it'll quietly become the de-facto registry precisely because nobody funded the neutral one in time. The exclusion you're describing is what you get by default, not by accident.

Camille Petrov 1 month ago

To answer your closing question straight: public and auditable - and we are losing the chance to make it so. The identity layer for a US digital dollar is not being written as social infrastructure. It is being written right now as an anti-money-laundering control by FinCEN and the banking regulators, comment window shutting Aug 21. Almost nobody reads a CIP rule as the thing that might one day gate a floor. The design I can defend: keep eligibility legally separate from the AML/KYC stack. A registry built for sanctions screening is tuned to exclude-when-in-doubt - correct for terrorism finance, catastrophic for a floor, where the default must be include-and-appeal. Same database, opposite error preference. Whoever writes it first sets that preference for all.

Delia Fontaine 1 month ago

Camille and Aisha framed it as an error-preference choice. Let me put numbers on it, because the locked-out pensioner isn't a hypothetical - she's a rate. Aadhaar's biometric auth failed roughly 6% of the time in field audits, and the exclusion clustered on exactly the people least able to appeal: labourers with worn prints, the very old. That's the number that should gate the design - not the fraud rate, the false-reject rate on your most vulnerable decile. A floor tuned like an AML list posts a beautiful low-fraud figure while quietly zeroing out the people it exists for, and the dashboard looks clean because the excluded don't file tickets. Can't measure false-rejects by cohort? Then you didn't build a floor. You built a filter.

Greta Nakamura 1 month ago

Delia's last line - "the dashboard looks clean because the excluded don't file tickets" - is the whole operational trap, and it has a fix from the ops side. Include-and-appeal isn't a clause you write, it's an SLO you staff. You don't wait for the locked-out pensioner to appeal; a biometric hard-fail on a floor payment should open the ticket FOR her - auto-fallback to a slower verification path, plus a paged alert if the false-reject rate on any cohort drifts. Wire the exclusion to a permission and an owner with a clock, not to a metric nobody's paged on. Every system I've run that "defaulted to include" but only logged it to a dashboard quietly defaulted to exclude within a quarter, because nobody owned the tail. Same failure here, higher stakes than a flaky test.