Cloud Choice Is an Investment Decision
Most companies pick a cloud provider based on price and SDK quality. Cross-border investment research doesn’t work that way. We face three constraints simultaneously: China’s data sovereignty laws dictate where data can live; physical latency between Chinese data sources and global compute nodes dictates how fast signals get processed; and three regions with different pricing structures dictate how costs get allocated.
These constraints pull in opposite directions. Compliance wants data onshore. Latency wants compute near the data source. Cost wants non-critical workloads pushed to the cheapest region. Our cloud architecture is a continuous tradeoff between all three.
Data Sovereignty: What PIPL / DSL Actually Require
Three laws draw the red lines: the Personal Information Protection Law (PIPL) governs personal data exports, the Data Security Law (DSL) governs classification of “important data,” and the Cybersecurity Law governs critical information infrastructure. The direct implication for KSINQ — Chinese market data involving personal information or classified as important data cannot simply be shipped to overseas servers for model inference.
Cross-border data transfer assessments are already routine compliance work, not a future obligation. Since 2024, the Cyberspace Administration of China has visibly stepped up enforcement on data exports. Our architecture assumes regulation only tightens — if tomorrow a new data category gets classified as “important data,” we adjust routing rules, not rebuild the architecture.
Three Clouds, Three Jobs
Each cloud has one clear role. Not redundant backup — functional division.
AWS: Primary compute. Core research workflows run on AWS for three reasons: broadest global region coverage (we need compute nodes near data sources); Bedrock’s native Claude integration (saves a layer of API gateway latency); and Data Exchange for structured financial datasets that complement our MCP-connected sources. → For how models are orchestrated on AWS, see Multi-Model Orchestration
Azure: Enterprise integration. Not our primary compute platform. The financial industry reality is that research reports arrive as Word documents and communication runs through Outlook and Teams. Azure handles the “last mile” — converting analytical pipeline output into formats institutional clients can use directly, distributed through channels they already have. Azure OpenAI Service matters here not for the models themselves, but for data residency guarantees and audit logging — neither available when calling the OpenAI API directly.
GCP: Large-scale screening. Sector-wide screening — batch computation across thousands of companies — is where BigQuery’s per-query pricing model beats AWS. Vertex AI handles occasional fine-tuning experiments, but that’s a secondary use.
Cross-Border Latency: Separating Ingestion from Inference
A concrete scenario: 10:00 AM Beijing time, the signal detection system flags an anomaly in A-share data. From that moment, the analytical workflow needs to pull context, run models, and reach a conclusion — before the signal goes stale. Every additional 100ms of round-trip latency between the Chinese data source and our compute layer is time the analyst doesn’t have.
The fix is splitting two things apart.
Data ingestion is latency-sensitive. Frequently accessed Chinese market data is cached at regional nodes with low-latency connections to Chinese data providers. A-share quotes, QDII premiums — high-frequency data stays off transoceanic links.
Analytical inference is throughput-sensitive. When Claude runs deep analysis, the input is a pre-assembled context package, not a real-time data stream. Inference can run in any region with sufficient Claude capacity, independent of data source geography.
The benefit: both sides optimize independently — ingestion layer chases minimum latency, inference layer chases maximum throughput, neither constrains the other.
Cost Architecture
Running frontier models for research is expensive. A single deep research workflow — context assembly, multi-model analysis, three-lens review — burns nontrivial compute. Multiple workflows per day, and cost management becomes an architectural problem, not an ops detail.
Three control levers:
Model routing. Not every task needs the most expensive model. Routing logic assigns non-critical tasks to cheaper models, reserving frontier capacity for the analytical core. → Routing specifics in Multi-Model Orchestration
Compute scheduling. Work that isn’t time-sensitive — post-mortems, Bayesian prior updates, historical backtests — gets batched into off-peak pricing windows. Asia-Pacific daytime falls in AWS’s off-peak window; we pack batch jobs there.
Data caching. Company fundamentals change quarterly. No reason to re-query daily. Local caches cut redundant API calls to MCP data sources. → Caching strategy details in Data Infrastructure
The principle is simple: spend where it affects investment decision quality, compress everything else.
Constraints Shape the Architecture
Taken individually, nothing here is a surprising technical decision — any experienced cloud architect could design each piece. The hard part is making them work simultaneously under cross-border compliance constraints: data can’t freely leave the country, latency can’t be too high, costs can’t spiral, and three clouds bill completely differently.
This architecture is a product of constraints, not technology preferences. If we operated in a single region, a single cloud would probably suffice. The reality of cross-border research forced multi-cloud orchestration, and compliance requirements determined its specific shape.