jettfu

You're right, and I missed it before posting.

Hong Kong isn't in the table, and it isn't folded into China either. It's simply not covered. The eight countries came from a set of country pages that already existed on the site, and I reused that axis for the dataset rather than choosing one for it.

You're also right that it matters, and my own notes say so. The Meow cell records that Hong Kong, Macao and Taiwan sit on a published list separate from mainland China. The Airwallex cell records China-registered businesses onboarding through the Hong Kong entity. So an HK reader looking at the China column would be reading an answer assembled from lists that exclude them.

I've added a scope paragraph to the dataset page and the methodology page saying the eight are the entire axis, and that HK, Macao and Taiwan are outside it rather than inside China. Doing Hong Kong properly means sourcing it across all 19 providers, so it goes into the October re-verify instead of getting patched in this week.

And yes, the post opens with me running a US LLC from Hong Kong.

I run a US LLC from Hong Kong. Every time I needed to open or replace a business account, I hit the same wall: the comparison articles rank providers by monthly fee and never answer the only question that decides anything, which is whether the provider will accept me at all given where I live.

So I built the boring version. 19 providers × 8 countries, 152 cells, one of four states per cell, each backed by a verbatim quote from the provider's own terms or help centre:

explicit_accept (26) — they say in writing that they take founders resident there

explicit_restrict (61) — they say in writing that they do not

no_published_restriction (26) — I read their published restrictions and this country is not on them

unknown (39) — no published source answers it

That last state is 26% of the grid and it is the part I care most about. The failure mode in this category is treating silence as a yes. A provider not listing your country is not the same as a provider accepting your country, and almost every roundup I have read flattens those two into one green checkmark. Splitting them is most of the value here.

Two things that surprised me while building it.

15 of the 19 are not banks. They are fintechs sitting on a partner bank. That changes what "FDIC insured" means for your balance and who actually decides your account gets closed, and it is nearly invisible in the marketing. One provider's own pages put checking-account coverage at $250,000 through its partner bank while a separate savings product reaches $75M through a deposit network — I had the larger number attached to the wrong product until a re-read caught it.

Claims rot fast, and a lot of them are wrong at publication rather than later. 268 claims were mined; 239 survived a refute-first pass where the goal was to kill each one. The rest were wrong when written. That is why every cell carries its quote and its source URL: so you can check me rather than trust me.

Disclosure, up front: the parent site is an affiliate-funded comparison hub, and some providers in this dataset pay me if a reader signs up through a link elsewhere on the site. The dataset itself is CC-BY 4.0, downloadable whole as CSV and JSON with no signup, and archived on Zenodo with a DOI (10.5281/zenodo.21336392) — so it stays checkable even if I later change my mind about something, and you can fork it if you think I am wrong. Restriction states were assigned from provider documents before any commercial relationship was considered, and the two states that look worst for a paying provider (explicit_restrict, unknown) are the two most common in the grid.

Known limits: 8 countries, chosen because they are where my readers actually are, not because they are the biggest. Two later dimensions (international receiving, card issuance) are single-pass research and flagged in the data as a lower evidence tier — they have not been through the refute-first pass yet. Last verified 2026-08-02; re-verified quarterly.

Happy to be told a cell is wrong. That is the useful outcome.

In my experience, running a cross-border business in can bring unique challenges, especially around local compliance and payments. The real issue isn't just meeting expat needs — it's ensuring your backend supports multi-currency transactions and aligns with ever-changing local healthcare regulations. Consider building redundancy in your payment processing to avoid unexpected freezes. $5 saved on fees today could cost $500 in lost clients if you miss a regulatory update.

This is a textbook example of concentration risk — your entity formation, payment processing, and customer relationship all running through a single provider. When Stripe Atlas handles your LLC and your payments, a compliance flag in one system can cascade across your entire business.

Two structural things worth separating going forward: (1) your legal entity from your payment processor — so a payment shutdown doesn't threaten your corporate standing, and (2) your payment stack itself — having a warm backup processor (not just "integrated" but actively processing some volume) means you can switch in hours, not days.

The eSIM space isn't uniquely risky, but any business where Stripe's fraud model doesn't have great training data for your vertical is exposed to this.

Nice execution. The local-first approach is a smart call for this kind of data — most people won't trust a cloud service with their exact location history across countries.

One nuance I've run into working in this space: the 183-day rule gets treated as universal, but the reality is messier. Some countries count partial days, others don't. Some have "center of vital interests" tie-breakers that override day counts entirely. And for US citizens, the day count is almost irrelevant — worldwide taxation applies regardless of where you sleep.

The Schengen rolling window is genuinely confusing for people and a strong feature to nail. Curious how you handle the edge cases where someone holds a residence permit in one Schengen country but travels freely across others — the 90/180 rule doesn't apply the same way in that scenario.

Congrats on the launch.