Where data sits is only the first question. Multinationals also need to know who can administer the systems around it, change the software, support production and prove that restricted personnel cannot exercise authority they are not supposed to have.

That is the useful lesson from the dispute now surrounding Webull. On October 7, the bipartisan House Select Committee on China published findings arguing that Webull’s China-linked technology structure created risks for U.S. investor data. Webull rejected the committee’s conclusions two days later, saying U.S. customer information is stored on AWS infrastructure in the continental United States, sensitive access is controlled by U.S.-based supervisors, and employees in China cannot access sensitive U.S. customer information.2, 3

The disagreement exposes a broader design problem. Data residency can establish where information is stored. It does not, by itself, establish who can act on the systems that store, process, support or change it.

The case is about control, not a proven breach

The Webull case needs careful handling. The committee alleges that the company’s operating model leaves U.S. investor data exposed to PRC legal and surveillance risk. Webull says the report relied on an incomplete record and identified no actual instance of improper customer-data access, transfer or misuse.1, 3

One fact is not in dispute. Webull’s own annual report says its mainland China subsidiary, Hunan Weibu Information Technology, employed 863 people at the end of 2025, about 62% of the company’s workforce. The same filing describes its mainland China operations as research and development and technical support, and identifies Hunan Weibu as a technology support and development subsidiary.4

That establishes substantial technology involvement in China. It does not establish that China-based personnel accessed protected U.S. customer data.

The issue at hand isn’t simply whether Webull “sent data to China.” The more consequential question is whether a regulated enterprise can demonstrate effective separation when its data sits in one jurisdiction but significant technology capability sits in another.

A data map does not show who holds authority

Traditional data-governance exercises often begin with location: what data exists, where it is stored, where it is transferred and which legal entity holds it.

Important though that is, it’s not the full picture.

A modern platform is operated through a myriad of permissions, development pipelines, support processes, authentication systems, monitoring tools and third-party services. Someone does not need to copy a customer database to exercise meaningful influence over the environment around it. Code changes how information is processed. Administrators change permissions. Support teams interact with production systems.

The House report itself focuses on this distinction, questioning whether PRC-linked personnel, affiliates or providers can access, support or influence systems handling U.S. customer data even where storage is domestic. Webull contests the committee’s interpretation of its controls.1, 3

For a cross-border platform, the control map therefore needs to answer questions a storage map cannot:

  • Who holds privileged or administrative access?
  • Who can approve, change or deploy production code?
  • Which teams can support live systems, and from which jurisdictions?
  • Which suppliers or affiliates sit in the authentication, monitoring or support chain?
  • What evidence can prove that restricted authority was not exercised?

Those questions do not imply that every function should be brought in-house. They establish what the enterprise needs to know about functions it does not own.

Enterprise control is not the same as ownership

This is where the Webull dispute becomes relevant beyond financial services.

Multinationals routinely rely on global development teams, regional shared services, outsourced infrastructure, cloud providers and local partners. Enterprise control cannot realistically mean that one company must own every server, application and engineering resource.

A more useful definition is narrower: the enterprise retains sufficient authority over access, change, dependency and evidence to remain accountable for the operating model.

That distinction works in both directions. A company can own infrastructure and still have weak control if privileged access is poorly governed. It can use a third-party platform and retain strong control if responsibilities, access boundaries, deployment rights and evidence are clearly designed.

Webull’s own filings illustrate the point. The company says its U.S. customer PII is held on U.S. servers and cannot be transmitted outside the country or accessed by non-U.S. employees without U.S. permission and oversight. At the same time, it acknowledges a substantial China-based research, development and technical-support organization.4

Whether those controls are sufficient is the disputed question. The architectural lesson does not depend on resolving that dispute: local storage and operational control are different properties.

The China question looks familiar in reverse

For multinationals operating in China, the same problem appears from the opposite direction.

A company may use Chinese cloud services, local engineering support or domestic infrastructure because its China operating environment requires them. That does not settle which controls should remain with the enterprise, which must sit with the China operation, or how the boundary between China and global systems should work.

What matters is whether the multinational can still exercise meaningful control over the China environment—and prove that control when challenged.

This is where apparently technical choices become difficult to unwind. Once the platform is live, gaps in control can stop being a compliance issue and start becoming an architecture problem.

Better yet, why not understand the control model before the architecture hardens?

Decide the authority model before choosing the platform

Before selecting or renewing a cross-border operating environment, leadership should be able to answer five basic questions in plain English. Where does the protected data actually sit? Who can act on the systems around it? How dependent is the business on overseas teams or suppliers? Which decisions must remain under enterprise control? And if challenged, what evidence would show that those boundaries worked as intended?

That is the practical lesson from Webull, regardless of how the dispute between the company and Congress is ultimately resolved.

It also explains where pre-deployment work creates value for multinationals entering or redesigning a China operating environment. What matters is whether those decisions have been made early enough to shape the infrastructure and vendor choices, rather than trying to recover control once the environment is already in place.

For Carolync, that means beginning before infrastructure selection with the data flows, privileged authority, third-party dependencies, China/global interfaces and evidence requirements the eventual environment will have to support. Infrastructure then follows the control model rather than forcing the enterprise to retrofit one later.

Related Carolync Insight: Architecture Has Become Strategy

The next generation of cross-border data architecture will be judged by more than where information resides. It will be judged by who can act on the systems around it, where that authority sits, and whether the enterprise can prove the separation it claims.