Why Cloud Choice Is an Investment Decision
For most technology companies, choosing a cloud provider is an infrastructure decision. For a cross-border investment firm operating between China and global markets, it is a regulatory, operational, and strategic decision with direct implications for research quality and compliance risk.
The specific challenges that make our cloud architecture different from a typical AI startup are threefold: data sovereignty requirements that govern where Chinese market data can be stored and processed; network latency between Chinese data sources and global compute resources; and cost optimization across multiple jurisdictions with different pricing structures. This article explains how we navigate these constraints.
The Regulatory Reality: China’s Data Governance
China’s data governance framework — comprising the Personal Information Protection Law (PIPL), the Data Security Law (DSL), and the Cybersecurity Law — imposes specific requirements on how data generated or collected within China is stored, processed, and transferred across borders. For KSINQ, this means that certain categories of Chinese market data and any personal information associated with our research process must be handled within architectures that comply with these regulations.
This is not a theoretical concern. Cross-border data transfer assessments are now a routine compliance requirement for firms that process Chinese data using infrastructure located outside mainland China. The regulatory environment continues to evolve, and our architecture is designed to adapt to tightening requirements rather than being built against current-state-only assumptions.
The Multi-Cloud Architecture
We operate across three major cloud platforms, each serving a defined function within our compliance and operational framework.
Amazon Web Services (AWS) — Primary Global Infrastructure. AWS serves as our primary compute and storage platform for global operations. The selection rationale centers on three factors. First, AWS offers the broadest global region coverage, which is essential for a firm that processes data from multiple jurisdictions and needs compute resources in geographic proximity to data sources. Second, AWS Bedrock provides native integration with Anthropic’s Claude models, which reduces latency and simplifies our primary reasoning workflow. Third, AWS Data Exchange provides structured access to financial datasets that complement our MCP-connected sources.
Our core research workflows — the multi-model analysis pipeline, the signal detection monitoring system, and the investment memo generation process — run primarily on AWS infrastructure.
Microsoft Azure — Enterprise Integration Layer. Azure serves a specific function in our stack: integration with the Microsoft 365 ecosystem that much of the financial industry relies on. Research reports arrive as Word documents and Excel spreadsheets. Client communication happens through Outlook and Teams. Azure OpenAI Service provides enterprise-grade access to OpenAI models with compliance features (data residency guarantees, audit logging) that the direct OpenAI API does not offer for certain regulated workflows.
We do not use Azure as our primary compute layer. We use it where its enterprise integration capabilities solve specific workflow friction — particularly in the “last mile” of research delivery, where outputs from our analytical pipeline need to be formatted and distributed through conventional enterprise channels.
Google Cloud Platform (GCP) — Data Analytics. GCP serves our large-scale data analytics needs. BigQuery handles the heavy computation when we run sector-wide screening across thousands of companies simultaneously — a task that generates query volumes where GCP’s pricing model is more favorable than alternatives. Vertex AI provides the environment for any custom model training or fine-tuning we undertake, though this is a secondary capability rather than a core workflow.
The Cross-Border Latency Problem
When our signal detection system identifies an anomaly in A-share data at 10:00 AM Beijing time, the analytical workflow needs to assemble context, run multi-model analysis, and deliver a Signal Alert before the signal becomes stale. Every additional 100 milliseconds of round-trip latency between the Chinese data source and our compute layer is time that the analyst does not have.
Our architecture addresses this through strategic placement of data caching and preprocessing nodes. Frequently accessed Chinese market data is cached in compute regions with low-latency connectivity to Chinese data providers. The heavy analytical reasoning — which is less latency-sensitive because it operates on assembled context rather than real-time streams — can run in any region with available Claude capacity. The separation of data ingestion (latency-critical) from analytical reasoning (throughput-critical) allows us to optimize each independently.
Cost Architecture
Running frontier AI models at research-institution scale is expensive. A single deep research workflow — context assembly through MCP, multi-model analysis, three-lens review — can consume significant compute resources per run. At the volume KSINQ operates (multiple research workflows per day across several active themes), cost management is not an afterthought; it is an architectural requirement.
Our cost optimization strategy has three components. First, model routing directs non-critical tasks to cost-efficient models like Google Gemini, reserving frontier model capacity for the analytical core. Second, compute scheduling batches non-time-sensitive workloads (post-mortem analysis, Bayesian prior updates, historical backtesting) to off-peak hours when cloud compute pricing is lower. Third, data caching reduces redundant API calls to MCP-connected sources by maintaining local caches of slowly-changing data (company fundamentals refresh quarterly; we do not re-query daily).
The principle underlying all three: spend compute budget where it directly impacts investment decision quality, and minimize spend everywhere else.
What This Architecture Enables
The end result is an infrastructure layer that handles the specific challenges of cross-border AI-powered investment research: regulatory compliance across jurisdictions, acceptable latency for time-sensitive signal detection, enterprise-grade integration for research delivery, large-scale data analytics for sector screening, and cost efficiency at production scale.
None of these capabilities is individually unique — any competent cloud architect could design each piece. What is distinctive is the integration across compliance boundaries, the multi-cloud orchestration tuned for cross-border financial workflows, and the cost architecture designed for AI-intensive research at production volume. This is the infrastructure equivalent of our investment philosophy: not any single brilliant decision, but a system of decisions that compounds into a durable advantage.