Three looks at systems under pressure: code review that can't keep up, GPU networks at hyperscale, and payment fraud shaped by authentication rules.
Picked from 51 new articles across 34 sources · arrow keys for other days
Today in 30 seconds
30s left
Imprint now lets about 10% of pull requests skip full review when CI rules them low-risk, after median review time rose from 33 to 77 minutes. story 1 ↓
Merges per engineer at Imprint quadrupled, which makes human review the bottleneck. Rule-based triage decides which changes still need a careful reviewer. story 1 ↓
Meta showed a two-tier, eight-plane GPU fabric, links that measure their own cable length to size buffers, and Ethernet replacing proprietary rack interconnects. story 2 ↓
Stripe ties lower card fraud to mandatory cardholder authentication: Asia Pacific now has its lowest fraud rate, and Latin America's runs up to 160% higher. story 3 ↓
1/3Will Larson (Irrational Exuberance)· Oct 17
Imprint lets some pull requests skip full review when CI rules them low-risk
Will Larson describes "small-change" at Imprint, a check in the build pipeline that marks low-risk pull requests for fast approval, using size, author experience and blast radius. So far about 10% of changes qualify.
Why it matters · Review is becoming the bottleneck as merge volume rises. This is a concrete, rule-based way to decide which changes still need a careful human reviewer.
Know this first
Context from the editor, not the article · 32 sec
1 · Why code review exists
Before a pull request (a proposed change) merges, a teammate reads and approves it. Teams use this to catch bugs, spread knowledge, deter insider abuse, and satisfy auditors. Regulated firms often have written controls requiring an independent human to approve certain changes.
2 · Checks gate merging
On GitHub, the CI/CD system (automation that builds, tests and deploys code) reports pass/fail "checks" on each pull request. Branch rules can require specific checks to pass before merging. Developers can't edit a check's result by hand the way they can edit a label.
3 · Review time scales with volume
2/3Engineering at Meta· Oct 12
Meta details its data center network designs at the 2026 Open Compute Summit
Meta presented its new network designs at the Open Compute Summit: 102.4 Tbps liquid-cooled switches, a flatter eight-plane fabric, a petabit-scale layer that joins regions into one cluster, and Ethernet inside the rack.
Why it matters · These are real design choices at hyperscale: removing a tier, measuring cable length to size buffers, and weighting routes by surviving capacity. Ideas like these feed the open switch software and specs other operators adopt.
Know this first
Context from the editor, not the article · 33 sec
1 · Scale-up, scale-out, scale-across
Scale-up connects a few dozen accelerators inside one rack with very high bandwidth and low latency. Scale-out connects thousands of racks in a building, usually as a Clos network of switch tiers. Scale-across joins whole buildings or regions so they can act as one cluster.
2 · Lossless Ethernet and RoCE
RoCE runs RDMA (direct memory-to-memory transfers that bypass the kernel) over Ethernet. Because it handles packet loss badly, switches use PFC (Priority Flow Control) to pause a sender before the buffer overflows. Data already in flight still needs reserved buffer space, called headroom.
3 · OCP, FBOSS and SAI
3/3Stripe· Sep 22
Stripe data links falling card fraud to mandatory cardholder authentication
Stripe looked at billions of card payments from 2022 to early 2026. Fraud fell most in countries that require strong cardholder checks at checkout, and stayed highest in Latin America.
Why it matters · For engineers building payments, this shows that authentication rules and the type of second factor strongly affect fraud. The same checkout can carry very different risk from one country to the next.
Know this first
Context from the editor, not the article · 35 sec
1 · What 3D Secure does
3D Secure (3DS) is a card-network protocol. During an online payment, the card's issuing bank gets a chance to verify the shopper, either silently from risk signals or by asking for an app approval, a one-time code or a biometric check. Fraud liability usually moves from the merchant to the issuer.
2 · Strong Customer Authentication
SCA is a European rule from the PSD2 payments directive. Many online card payments need two of three factors: something you know (a PIN), something you have (a phone) and something you are (a fingerprint). 3DS is the usual way merchants meet it.
3 · Disputes and chargebacks
A cardholder can dispute a charge with their bank. If the dispute succeeds, the money is pulled back from the merchant as a chargeback. Dispute rates are a common stand-in for fraud, because victims dispute charges they never made.
If each engineer opens more pull requests but reviewer attention stays fixed, changes wait longer in the queue. Faster authoring then moves the bottleneck onto reviewers. Many teams ran into this as change volume rose sharply over 2024–2026.
Image: Will Larson (Irrational Exuberance)
At Imprint, a fintech company, the average engineer now merges four times as many 1 (PRs, proposed code changes) as two years ago. Some teams are at 10x. Will Larson reports that quality improved over the same stretch: incidents fell 42% and critical incidents fell 78% 2 (one six-month period against the previous one). Review is where the strain shows. Median review time went from about 33 to about 77 minutes, rising in step with merge volume.
Why review, exactly?
Larson splits review into four jobs and argues each now has a better tool:
Knowledge sharing: at this volume, teaching should happen across clusters of PRs rather than one PR at a time.
Catching errors:3 (the automated build-test-deploy pipeline) and verification built into the development harness work better than review.
Stopping malicious changes: careful reviewers usually miss competent attacks. Fixed rules, anti-abuse tooling and audit logs do better.
Compliance: Imprint's written controls still require an independent human reviewer in some repositories.
He still wants to change carefully, starting with a narrow, contained case.
The small-change check
When a PR is marked ready, CI/CD reports a 4 saying whether it qualifies. A visible label also appears, but people can edit labels, so only the build-controlled check counts. A PR qualifies only if all of the following hold:
It is under 1,000 lines.
The automated review bot reports no priority-1 or priority-2 findings.
The author has 10 or more merged PRs in every service touched.
It touches fewer than N services: 1 in the frontend 5, 3 in the backend one, since changes often span a 6 service and a shared HTTP gateway.
It doesn't touch shared libraries.
Its paths aren't excluded in a per-repo .small_change file. Money-movement code, for example, can be excluded.
A Slack emoji reaction flags qualifying PRs. A scripted sweep approves open small-changes that pass every check and stay clear of payments and security. A second workflow reviews batches of PRs for recurring themes. Any bug that gets through is treated as a system failure, fixed by improving checks rather than blaming people. Rollout took about two days.
Imprint also runs 7, a cloud harness that writes and verifies changes and decides how many reviewers each one needs, sometimes just one human.
Early days
About 10% of changes qualify so far. Larson says the concept works, but success depends on growing that share by making verification more comprehensive. That is harder in Imprint's domain-heavy software, where users' configurations differ so much that 8 cover less. The article doesn't report incident data for small-changes, or explain how the compliance requirement fits with automated approval. Some engineers are uneasy about questioning a long-held practice.
Will Larson, an engineering leader at the fintech company Imprint, describes the company's first attempt at a review bottleneck that most fast-moving teams now share. Over two years, the average Imprint engineer went from merging some number of 1 (PRs, proposed code changes) per week to four times that. Two teams are at 10x, and one engineer merges 25x what the average engineer did two years ago. Larson expects the average a year from now to look like today's 2 (the 90th percentile) rather than today's p50 (the median).
He says quality got better, not worse. Incidents are down 42% 3 (comparing one six-month period with the previous one), and critical incidents are down 78%. Larson takes this as more evidence that the usual "quality versus velocity" trade-off isn't a useful way to think.
The cost showed up in review. Median time to complete a PR review rose from about 33 minutes to about 77 minutes, and Larson says it tracks merge volume closely. Imprint's response is a mechanism it calls small-change. He is open that it hasn't solved the problem.
Unbundling what review is for
Larson's argument begins by splitting review into the four jobs it does. For each, he says something else now does the job better:
Knowledge sharing. Engineering is learned largely by apprenticeship, and review is how experienced engineers teach. At current volumes, he argues, that teaching has to move from single PRs to of PRs, looking for themes across many changes.
So Larson thinks every job has a better tool available. He still wants to move cautiously: find a narrow, contained case, validate the new practice there, then widen it.
How small-change works
When a PR is marked ready, CI/CD decides whether it is eligible and reports the answer as a 5. A label also appears so people can see it at a glance. Labels can be edited by hand, though, so the check, which only the build controls, is what counts. Tooling may filter by the label but always re-verifies the check.
A PR qualifies only if it meets all of these:
Under 1,000 lines of code.
No priority-1 or priority-2 findings from Imprint's automated review bot.
The author has "experience" in every service or application touched, defined as 10 or more previously merged PRs into that service's directories.
It touches fewer than N distinct services. N is 1 in the frontend 6 (one repository holding many projects). N is 3 in the backend monorepo, because a typical change edits both a service (gRPC is a remote-procedure-call framework) and a shared HTTP gateway.
Here is a worked example with illustrative numbers. An engineer with 40 merged PRs in the billing-notifications service changes 300 lines there and the matching route in the HTTP gateway, where they have 15 merged PRs. The bot finds nothing serious, and no shared library is touched. That is two services in the backend repo, below the limit of three, so the PR qualifies. If the same engineer also changes a shared date-utility module, it doesn't. It also doesn't qualify if a new hire with 4 gateway PRs writes it.
Two pieces of tooling sit around the check. Imprint's Slack bot already adds emoji reactions ("reacji") to every PR link showing its state, such as failing tests or ready to merge. It now has a small-change reaction too, so reviewers can spot fast-path candidates. There are also two reusable scripted workflows ("skills"). review-small-change sweeps given repositories for open small-changes and approves those that pass every check and don't touch sensitive areas like payments or security. review-pr-cluster reviews batches of PRs to surface recurring themes worth discussing or turning into new automated checks. That second workflow is where the knowledge-sharing job ends up.
The social rule matters as much as the technical ones. Any error that gets through a small-change counts as a failure of the system, not of the author or approver. The fix has to go into the review bot, the verification steps, CI/CD or the harness. Building and rolling all this out took about two days of part-time attention. Larson expects the tuning to go on far longer, "maybe forever."
A second approach: 8
Imprint also runs fleet, a centrally orchestrated cloud harness that writes and verifies code under tight control. Independent evaluators decide how many reviewers each change needs, which can be as few as one human for changes judged safe. Larson compares it to Stripe's internal "Minions" system, minus Minions' one-shot style. The article gives little detail beyond that.
Results and limits
Larson calls it too early for meaningful results. About 10% of changes qualify, and most of those get fast approval unless they touch security- or money-adjacent code. He considers the idea proven. Whether it succeeds now depends on raising that share over the coming months, which depends in turn on making verification more comprehensive.
He makes a distinction here that matters. Techniques like 9 (releasing to a small slice of users first) work best in software with high scale complexity and low domain complexity, where most users behave alike. Imprint's software is the reverse: modest scale, complex domain, and users with very different configurations. A canary there covers less ground, so verification has to come from harder techniques. The article doesn't say which.
Some things are left open. The article doesn't report whether small-changes have caused any incidents yet. It doesn't say how the compliance requirement for independent human review is met when approval comes from an automated workflow, or why 1,000 lines and 10 PRs were chosen as thresholds. Nor does it explain how "touching sensitive topics" is detected.
Larson also admits the reception has been mixed. Engineers are being asked to question a practice many of them built their careers on. His summary: re-examining old practices every week is energising, and teams that stop doing it will likely fall behind.
Remember
The eligibility signal is a build-controlled check, not a human-editable label. That keeps the fast path hard to game.
Bugs that get through are treated as system failures, fixed by improving automated checks rather than blaming the author or approver.
Incremental rollouts cover less when users' configurations differ widely, so domain-heavy software needs other verification methods.
The Open Compute Project (OCP), co-founded by Meta in 2011, publishes open hardware designs. FBOSS is Meta's open-source switch operating system. SAI (Switch Abstraction Interface) is a standard API that lets the same software drive switch chips from different vendors.
IcePack: Meta's first liquid-cooled network rack, filled with 102.4 Tbps IceCube switch blades.1 / 4
At the 2026 1 Summit, Meta described the networks behind its training clusters, from inside a rack out to links between regions. The post is a roundup with few measurements, but several design choices stand out.
Faster switches, fewer tiers
IceCube is a 102.4 Tbps switch blade with 128×800G ports, double the previous generation. It comes in Broadcom and NVIDIA versions, sits in Meta's first liquid-cooled network rack (IcePack), and runs 2, Meta's open-source switch operating system.
Flattened Planar Fabric (FPF) connects each GPU through eight separate 100G links to eight switches, one per independent network "plane." Because each plane uses many narrower ports, a two-tier 3 network (layered leaf and spine switches) can reach more GPUs. That means FPF can drop the third tier of Meta's older fabric, which cuts hops, latency and cost. The NIC (network card) sprays packets across all eight planes in hardware. Hosts and switches share one control plane, so hosts can route around a failed plane.
Stretching one cluster across regions
Meta's Prometheus cluster is about 1 GW, too large for one region. Backend aggregation (BAG) is an Ethernet layer that sits above the building fabrics and joins them into one cluster. Between a pair of regions it carries tens of petabits per second.
Distance causes a buffering problem. Lossless Ethernet uses 4 (Priority Flow Control) to pause senders before a buffer overflows. But data already on the cable keeps arriving, so the receiver needs reserved space for it, and longer cables need more. Instead of sizing every link for the worst case, FBOSS times probe packets to measure each cable and reserves exactly what that length needs.
BAG weights routes by the capacity each path has left, using 5 signaling, and damps changes so one failed link doesn't cause routing churn. Crossing regions adds several times the latency of staying inside a fabric. To limit the damage, Meta's job scheduler keeps collective traffic (group operations across many GPUs) off BAG where it can.
Ethernet inside the rack
Tahan is a 51.2T switch. Four of them connect 16 of Meta's MTIA accelerators at 6.4 Tbps each, running the same lossless 6 (7 over Ethernet) stack as the wider network. A next-generation blade will connect 72 accelerators per rack and later adopt 8, an open spec for Ethernet in this role.
Open platforms
OSPA, a new spec led by Meta, Microsoft and Alibaba, aims to standardize switch hardware management (power, sensors, firmware), which is still custom for every platform. Meta also released open-source code for MetaRoCE, its RDMA transport protocol. The post gives no performance numbers for FPF or BAG.
At the 2026 1 Global Summit, Meta's Network Infrastructure team showed the networks behind its training clusters. They cover every scale: inside a rack, across a building, and between regions. The post reads like a conference roundup and gives few measurements. What makes it useful is the engineering choices it names.
Twice the bandwidth per switch, now liquid-cooled
The new switch blade is IceCube: 102.4 Tbps with 128×800G non-blocking ports, which doubles the previous 51.2T generation. One version uses Broadcom's Tomahawk6C ASIC (the switching chip) and the other uses NVIDIA's Spectrum-6. Both run 2, Meta's open-source switch operating system, on top of 3 (Switch Abstraction Interface), a standard API for switch chips. The blades sit in IcePack, Meta's first liquid-cooled network rack, built to OCP's ORV3-HPRv1 rack standard. The reason for liquid cooling is power density. At this bandwidth, air can no longer remove the heat from a dense rack of switches.
Flattened Planar Fabric: the NIC becomes part of the network
The biggest architectural change is Flattened Planar Fabric (FPF). Each GPU no longer has one fat uplink. Instead, its network card (NIC) connects through eight independent 100G links to eight different switches. Each switch belongs to a separate "plane," a complete parallel network. Meta claims four benefits:
Fewer tiers. The previous fabric, called NSF, was a three-tier network (a layered mesh of leaf and spine switches). FPF needs only two tiers. That removes a layer of switches, which cuts hops, latency and cost.
Meta built FPF with NVIDIA using Spectrum-X Multiplane features. The two companies are also helping cloud providers standardize their multiplane fabrics based on what FPF taught them.
Making rented GPUs behave like owned ones
Meta says it can't build data centers fast enough. Construction takes years, while demand changes within months. So it also uses leased facilities and public cloud capacity. That only works if the network behaves the same everywhere, and clouds differ:
Fabric topologies vary from provider to provider.
Switch buffers are often shallower.
5 (direct memory-to-memory) transports are provider-specific.
Some clouds still run InfiniBand instead of Ethernet.
Meta's answer has two parts. Before handing over a cluster, providers run a standard set of point-to-point and collective benchmarks (tests of group operations across many GPUs), from tens of GPUs up to more than a thousand. Meta also maps each provider's traffic classes and congestion-control settings onto its own lossless RDMA classes. The team's rule of thumb: "heterogeneity is manageable but standardization is what makes it affordable."
BAG: one cluster across regions
Meta's Prometheus cluster is about 1 GW in 2026, and Hyperion is heading toward 5 GW. Clusters that big no longer fit in one region. Backend aggregation (BAG) is an Ethernet super-spine, a layer above the building fabrics, that ties many of them into one cluster. Capacity between a pair of regions reaches tens of petabits per second. Prometheus already spans regular data center buildings, weatherproof outdoor structures and nearby colocation space.
At this distance, the physics changes. With lossless Ethernet, 6 (Priority Flow Control) tells an upstream switch to pause before a buffer overflows. But data already on the cable keeps arriving after the pause is sent, so the receiver must reserve buffer headroom for it. That headroom grows with cable length. Here is an illustrative calculation: light in fiber travels about 5 µs per km, so a 10 km link has a round trip of roughly 100 µs. At 800 Gbps, that is about 80 Mb, or 10 MB, of in-flight data per port per lossless class. That is a big share of a switch chip's shared buffer. If headroom is too small, packets drop. If PFC pauses spread backward through the network, congestion travels far beyond the link that caused it.
Sizing every link for the worst-case distance wastes buffer, so FBOSS now measures each link. It sends probe traffic on an uncongested queue, times the round trip, works out the cable length, and allocates headroom to match.
BAG also has to handle paths that are degraded rather than fully down. It uses 7 signaling, a BGP extension that advertises how much capacity each path has left, so traffic is split in proportion to what actually remains. Deliberate damping stops one failed link from setting off routing churn across the whole domain.
Latency is the harder problem. Traffic between fabrics takes several times longer than traffic within one. Collective communication libraries pick their algorithms without knowing network distance, so they can hit a performance cliff. Meta is attacking this from two sides: adaptive routing to shrink the latency penalty, and job scheduling that keeps less collective traffic on BAG in the first place. When a replica fails, training drops it and the rest keep synchronizing. For the regional backbone, Meta runs 8 (Segment Routing over IPv6, where the sender encodes the path in the packet header) on FBOSS, using shallow-buffer switches built on Cisco Silicon One chips.
Ethernet inside the rack
Scale-up links, which connect accelerators inside a rack, have usually relied on proprietary interconnects. Tahan is a 51.2T Tomahawk 5 switch with 64×800G ports, half of them facing the accelerators over the backplane. Four Tahans connect 16 MTIA 300 accelerators (MTIA is Meta's in-house chip) in a non-blocking topology, giving 6.4 Tbps per accelerator. Tahan runs the same lossless 9 stack as the scale-out network: routed IPv6, PFC and AI-tuned QoS (Quality of Service, which prioritizes traffic classes). So one operating system manages both. The next scale-up blade is a 216×400G Tomahawk6C switch, and eight of them connect 72 accelerators per rack.
A future version of that blade will use 10 (Ethernet for Scale-Up Networking) as its data plane. ESUN is an OCP effort Meta started in 2025 with AMD, Arista, ARM, Broadcom, Cisco, HPE, Marvell, Microsoft and NVIDIA. ESUN 1.0 specifies what the fabric must deliver and leaves accelerator design to vendors. It aligns with the IEEE and the Ultra Ethernet Consortium (11). Version 1.1, nearly finished, adds switch profiles and a shorter inter-packet gap (the idle time required between Ethernet frames).
Opening the platform layer
SAI made the data plane portable across chips. The platform layer beneath it is still custom for every box: power sequencing, sensors and fans, hardware inventory, management ports, firmware updates and diagnostics. Bringing up each new platform takes months of duplicated work. OSPA (Open Switch Platform Architecture), led by Meta, Microsoft and Alibaba, aims to standardize that layer, and its v1.0 spec has been submitted to OCP. FBOSS now lets vendors port it to their own hardware without Meta engineers. Meta also released open-source implementations of MetaRoCE, its RDMA transport protocol with congestion control and reliability tuned for collective traffic.
What's left open
The post gives no latency or throughput results for FPF and no failure-recovery times for BAG. It also doesn't say how well the probe-based cable measurement works. MetaRoCE's congestion-control design isn't described at all.
Remember
FPF spreads each GPU's traffic over eight parallel planes, letting a two-tier Clos replace three tiers and shifting load balancing into the NIC.
Over long distances, lossless Ethernet needs buffer headroom that grows with cable length, so FBOSS measures each cable's length and sizes buffers to match.
Meta now runs the same lossless RoCE stack inside the rack as across the building, replacing proprietary interconnects.
Stripe's card fraud trends by region; Asia Pacific drops below EMEA in Q1 2026.1 / 2
Stripe analyzed billions of card transactions on its platform from January 2022 to March 2026. The pattern: card fraud fell fastest where regulators require strong checks that the person paying is the real cardholder. In the first quarter of 2026, Asia Pacific had Stripe's lowest card fraud rate of any region for the first time in the study period.
One caveat first. Stripe gives only relative changes, not absolute rates or how it measures them, and the post ends in a product pitch.
Why this matters
Stripe says 36% of its businesses sell into more than one country, and the number selling into over 100 countries has quadrupled in five years. Fraud risk varies widely by market. In 2025, Latin American businesses saw fraud rates 160% higher than businesses in Europe, the Middle East and Africa (EMEA).
The mechanism
1 is a card-network protocol that lets the card issuer verify the shopper during an online payment. The issuer either approves silently from risk signals or asks for proof: an approval in the bank's app, a 2 sent by text message, or a biometric check. Europe's 3 rule requires two-factor checks like these on many online payments.
Results by region
Caveats
The closing section promotes Stripe's 6 fraud product. It claims a 1.20% gain in completed checkouts and a 7.67% cut in fraud from Stripe's 3DS tuning, without saying how those were measured. The data shows correlation, not proof that mandates caused the declines. The post also doesn't address how much extra authentication costs in abandoned checkouts.
Stripe analyzed billions of card transactions on its platform from January 2022 to March 2026, broken down by region and country. The main finding: the countries where card fraud fell fastest tend to be the ones that require extra cardholder checks on online payments. In the first quarter of 2026, Asia Pacific had the lowest card fraud rate of any Stripe region for the first time in the study period. Latin America stayed the highest.
A caveat before the numbers. Stripe gives only relative changes, never absolute fraud rates, and never says exactly how "fraud rate" is measured. It could be share of transactions, share of payment volume, or something else. The post ends in a product pitch. Read the figures as one large payment processor's view of its own merchants, not as an industry baseline.
Why regional variation is an engineering problem
Stripe says 36% of businesses on its platform now have customers in more than one country, and the number selling into over 100 countries has quadrupled in five years. Each new market brings its own fraud patterns, habits around authentication and regulations. Stripe says businesses often handle this with a separate risk strategy, and sometimes a separate team, for each market. The gaps are large: in 2025, Latin American businesses saw card fraud rates 160% higher than businesses in Europe, the Middle East and Africa (EMEA), and 151% higher than those in Asia Pacific.
How the mechanism works
The tool behind most of the improvements is 1, a card-network protocol that adds a verification step to online card payments. Here is how it works:
When a shopper checks out, the merchant sends payment and device details to the card issuer.
The issuer decides whether to approve the payment silently, based on risk signals, or to challenge the shopper.
A challenge might be an approval in the bank's app, a 2 sent by text message, or a biometric check.
How strong that challenge is matters a great deal, as the Iberia case below shows.
3 is the European regulation, from the PSD2 payments directive, that requires two-factor authentication on many online card payments. 3DS is the usual way merchants comply. The article argues that SCA gave European issuers both the framework and the time to build more sophisticated fraud systems.
Asia Pacific: mandates that bite
Several Asia Pacific markets have made 3DS mandatory. Malaysia had the largest drop in the region, with card fraud rates down 74% from 2022 to 2025. Stripe credits the strictness of the central bank's rules. Banks must:
use multifactor authentication
move customers from text-message OTPs to authorization inside a secure banking app
let customers freeze their accounts immediately
All three reduce the number of unauthenticated or easily hijacked transactions.
Japan's fraud rates fell every year from 2022 to 2025. Japan's 3DS mandate took effect in April 2025, and Stripe says dispute rates in 2025 were more than 30% lower than in the same period of 2024. Disputes are a proxy, not a direct measure of fraud. The article doesn't separate the mandate's effect from other trends that were already pulling fraud down.
Europe: same rule, different outcomes
European fraud rates fell 21% from 2022 to 2025, but unevenly:
France: down 40%. Stripe points to history. France adopted 4 early, so cardholders were used to two-factor checks years before SCA. Familiar users are more likely to complete authentication successfully.
Great Britain: down 27%.
Iberia: up every year. It was the only named European region where fraud rose in each year of the study. Spain and Portugal lean more on text-message OTPs than biometrics or app approvals, and both are heavy targets of "5", SMS phishing in which attackers pose as banks to steal card details and codes.
Iberia is the most instructive case. It falls under the same SCA rule as France, but its weaker second factor appears to undo much of the benefit. A text-message code is only as secure as the user's ability to resist a convincing fake text. An approval inside a bank app is much harder to phish.
Latin America: structural headwinds
Latin America has had the highest fraud rates on Stripe since January 2022. In 2025 they were 65% above North America, 151% above Asia Pacific and 160% above EMEA. Ecuador, Panama and Brazil improved. Stripe gives three structural reasons the region stays high:
Cash-heavy economies. Card fraud models have less history to learn from.
Dispute rules that favor cardholders. Merchants carry the burden of proof when a charge is contested.
Different rules in each country. Most markets require electronic invoicing, but formats and scope differ. In Mexico, digital service providers must give the tax authority, 6, permanent access to their transaction data. SAT queries individual transactions on its own schedule, and each one must be searchable within a day and kept for five years. That is a real data-retention and query-latency requirement for whoever stores the payment records.
The pitch, and what's left open
The final section promotes Stripe's products. Its fraud screening product, 7, now covers bank debits, wallets, real-time payments, stablecoins and cash vouchers. Stripe says its 3DS optimization gives businesses in SCA regions a 1.20% lift in conversion and a 7.67% cut in fraud on average. Those are vendor figures, and the post doesn't describe how they were measured.
Several things go unanswered:
the absolute fraud rates
how fraud is measured
whether changes in Stripe's own merchant mix by region account for part of the trends
how much of each decline comes from mandates versus issuers' own investment
what mandatory challenges cost in abandoned checkouts in places like Malaysia
The direction is plausible and fits what the industry already knows. The post shows a strong correlation, not proof of cause.
Remember
The type of second factor matters: Iberia's reliance on text-message codes left fraud rising under the same rule that cut France's by 40%.
Malaysia's strict rules (app-based approval, instant account freezes) went with a 74% fraud drop, the largest in Asia Pacific.
Stripe reports only relative changes, so the figures show direction, not absolute risk or proof of cause.
Preventing errors. Review has always been an expensive place to catch bugs. He argues that strong 4 (continuous integration and delivery, the automated build-test-deploy pipeline) plus verification inside the development harness works better. He cites "poteto's pstack" as an example but doesn't explain what it is.
Preventing malicious behaviour. In his experience, careful review usually misses competent attacks, though most attacks are incompetent. He'd rather rely on fixed rules ("changes to these files always need review"), anti-abuse tooling, auditing, and inspection of audit logs.
Compliance. Imprint's documented controls currently require an independent human to review changes in some repositories. Controls can be rewritten, but for now this one binds.
7
It doesn't touch shared libraries or utility files.
A per-repository .small_change file allows no path-level exclusions. For example, a money-movement service can be opted out entirely.
4
Larger non-blocking clusters. The post doesn't explain why, but standard Clos arithmetic does. A two-tier Clos built from switches with k ports can reach roughly k²/2 hosts. A 102.4T chip has 128 ports at 800G but 1,024 ports at 100G. That raises the two-tier ceiling from about 8,000 endpoints to about 500,000 per plane. These figures are illustrative; Meta doesn't give FPF's actual cluster size.
Load balancing in the NIC. The NIC sprays every packet across all eight planes in hardware. Spreading traffic used to be the switches' job.
Hosts in the control plane. Hosts and switches share one control plane, so a host can steer traffic away from a plane that has failed.
Malaysia: fraud down 74% (2022 to 2025). The central bank requires multifactor authentication, a move from text-message codes to approval in a secure app, and instant account freezes.
Japan: fraud fell every year. After its April 2025 3DS mandate, disputes (charges customers contest with their bank, a proxy for fraud) were more than 30% lower than a year earlier.
Europe: down 21% overall. France fell 40%, which Stripe partly credits to its early adoption of 4. Great Britain fell 27%.
Iberia: the only named European region where fraud rose every year. Spain and Portugal rely on text-message codes and are heavily targeted by "5", phishing texts that steal card details. Same rule as France, weaker second factor, worse results.
Latin America: highest since 2022, 65% above North America. Stripe cites cash-heavy economies that leave fraud models less data, dispute rules that put the burden of proof on merchants, and rules that differ by country. In Mexico, for example, the tax authority can query any transaction, which must be searchable within a day and kept for five years.
