We are building Nepal's AI-native neocloud: sovereign, on-soil GPU compute orchestrated by VajraCore and purpose-built for AI inference workloads, taking advantage of low electricity costs and a forward-thinking government to deliver distributed compute that's more capital-efficient than building data centers from scratch.
Our first go-to-market wedge is Nepal's 20 NRB-licensed commercial banks, regulated institutions that need sovereign, on-soil AI compute they cannot reliably or cost-effectively source from offshore hyperscalers. Banking is our proof-of-concept anchor and immediate revenue target, not the whole vision: it's the first chapter of a distributed, AI-native neocloud serving every Nepali enterprise, institution, and government agency that needs affordable, local AI compute.
Nepal is not a generic emerging market for AI infrastructure. It has three specific, structural conditions that make it an unusually attractive location to build a neocloud, conditions that exist together in very few places.
Nepal's hydro-abundant grid delivers electricity at approximately $0.061/kWh at business retail rates, and potentially lower at industrial scale. For AI compute, where power is the dominant ongoing OpEx, this is a structural cost advantage over neoclouds operating in the US (~$0.12/kWh), EU, or Singapore. Lower power cost means lower GPU-hour pricing and higher margin at the same price point.
Nepal's current government has actively positioned around digital infrastructure and AI readiness as national priorities. This is not just a regulatory-compliance story: it is a policy tailwind. A government that wants Nepal in the AI race is a potential customer, a potential partner, and a source of operational support that makes our environment materially friendlier than most emerging markets at a comparable stage.
Nepal's GPU and cloud infrastructure landscape is moving fast: DataHub's YetiCloud.ai, Ncell's licensed data center, and Bichuten's Tier IV build are all bringing sovereign, hydro-powered compute online. We're not building ground-up data centers to compete with them: we lease colocation space inside existing carrier-grade facilities, so we don't need their capital base to get started. What we build on top is different: a distributed, AI-native compute layer orchestrated by VajraCore, purpose-built for AI inference workloads, not the generic virtual-machine cloud Ncell sells or the raw hyperscale colocation Bichuten is building toward. That's a different business, with a different moat: workload-specific orchestration and service quality, not just raw GPU capacity or square footage.
A neocloud is a cloud infrastructure company that provides GPU-powered AI compute capacity (the same raw material that powers AI applications) but without the complexity, cost, and data-sovereignty compromises of the global hyperscalers.
Think of it this way: Amazon AWS, Microsoft Azure, and Google Cloud are the global supermarkets: enormous, everything available, but your data leaves Nepal the moment you use them, prices are set in USD at global rates, and you are one small customer among millions.
A neocloud is the local alternative: purpose-built for a specific market, with infrastructure physically located in that country, priced for local economics, and operated by people who understand and are accountable to local regulatory requirements. In Nepal's case, that means AI compute that stays inside Nepal, costs less than offshore alternatives, and is run by a team with direct relationships with the regulators and customers it serves.
Comparison reflects general market conditions. Individual AWS/Azure pricing varies by contract. Power cost comparison uses US average commercial rate (~$0.12/kWh) vs. Nepal confirmed business retail rate ($0.061/kWh, Sept 2025).
Three things converged in the last 12 months that didn't exist before. Each one alone is interesting. Together they create a window.
In February 2025, the Financial Action Task Force placed Nepal back on its Grey List for strategic deficiencies in its AML and counter-terrorism financing regime. Being grey-listed restricts international correspondent banking relationships and increases the cost of cross-border transactions for every Nepali bank. The NRB's response, the revised STR/SAR Guidelines 2025, explicitly mandates AI-supported compliance platforms and centralized KYC data integration. Nepal's banks are not choosing whether to adopt AI-driven compliance. They are being told to, by their regulator, urgently.
The revised 2025 STR/SAR guidelines formally require all reporting institutions (20 commercial banks, 17 development banks, insurance companies, and payment firms) to upgrade to AI-supported RegTech platforms and integrate Customer Due Diligence systems with Nepal's National ID-based KYC database. The mandate exists. The budget pressure exists. What does not yet exist is a sovereign, on-soil AI platform capable of running these workloads inside Nepal on infrastructure that satisfies NRB's own data-residency expectations. That is the gap we fill.
Three years ago, building a sovereign GPU compute platform in a small emerging market was prohibitively expensive relative to available revenue. The combination of falling GPU hardware costs, the maturity of third-party AI orchestration platforms (what we call VajraCore) that abstract the complexity of bare-metal AI infrastructure, and Nepal's structurally low power cost (~$0.061/kWh) means the unit economics now work at the scale Nepal's market can actually support, without needing to win 50 customers in year one.
A plain-language walkthrough of the kind of AI-driven compliance workload our infrastructure is built to run. This illustrates the technical capability: it's an example application, not a product we sell directly. No technical background required.
A commercial bank in Nepal opens thousands of new accounts every month across its branch network. For each new customer, the bank must:
Today, most of this is done manually or with basic rule-based software that generates enormous volumes of false positives, flagging legitimate transactions as suspicious and burying compliance teams in paperwork. NRB inspection reports consistently flag patchy KYC, insufficient transaction monitoring, and poor STR escalation as the primary compliance failures.
The consequences of getting this wrong are severe and getting worse:
The banks know they need to upgrade. The regulator is telling them to upgrade. The obstacle is not willingness: it is the absence of a capable, compliant, affordable platform they can actually use inside Nepal.
Here is an illustrative end-to-end flow for the kind of customer onboarding and AML monitoring application a bank could run on VajraCloudAI's infrastructure, orchestrated by VajraCore. The compliance application itself, the models and workflow logic, would be built by the bank's own development team, a systems integrator, or through project work with us; what we provide is the sovereign, on-soil compute and orchestration layer underneath it.
The bank's existing onboarding system (whatever software they currently use) sends the customer's submitted documents and information to our infrastructure via a secure API. The data never leaves Nepal: it travels from the bank's branch to our colocated bare-metal servers inside the country. No data crosses an international border at any point.
AI models for this kind of workflow (running on GPU hardware in our colocation facility, orchestrated by VajraCore) read the submitted citizenship card or national ID, extract the data, verify it against the National ID database integration (as now required by NRB's 2025 CDD directive), and flag any inconsistencies. What previously took a branch officer 20–30 minutes of manual checking now takes under 10 seconds, with a higher accuracy rate and a full audit trail.
While identity is being verified, a second AI process screens the customer's name and profile against international sanctions lists (UN, OFAC, EU) and Politically Exposed Person databases. This used to be a separate, manual step that compliance teams ran periodically, often days after account opening. In this setup it runs in parallel with onboarding, so a high-risk customer is flagged before the account is opened, not after.
The application produces a customer risk score (low / medium / high) with a plain-language explanation of the factors driving it. The compliance officer does not need to understand AI: they receive a recommendation ("approve," "review," or "escalate") with the reasoning attached. They make the final call; the AI handles the analysis. This keeps humans in the decision loop while removing the drudgework that currently consumes compliance team capacity.
Once the customer is onboarded, the application monitors their transaction patterns in real time, looking for the typology-specific red flags now listed in NRB's 2025 STR/SAR guidelines (unusual cash volumes, structuring patterns, rapid fund movement inconsistent with stated income). When a suspicious pattern is detected, the system drafts an STR pre-filled with the relevant transaction data and flags it for the compliance officer's review and submission to FIU-Nepal. The filing process that previously took hours of manual documentation now takes minutes.
Identity verification drops from 20–30 minutes of manual branch officer time to under 10 seconds, improving customer experience and freeing branch staff for higher-value work.
Continuous, AI-driven monitoring with a full audit trail directly addresses the patchy KYC and insufficient transaction monitoring that NRB inspection reports consistently flag as violations.
Every step of this process runs on hardware physically located inside Nepal. Customer data, transaction records, and compliance outputs remain under Nepali jurisdiction at all times: no offshore cloud routing required.
Running the five steps above reliably, at the transaction volumes a commercial bank generates, requires AI models running on GPU hardware, orchestrated so that multiple workloads (identity verification, screening, monitoring) can run simultaneously without conflicts. Building this orchestration layer from scratch would take a team of engineers 12–18 months and several million dollars. VajraCore (a third-party AI orchestration platform we plan to license, with several providers currently under evaluation) provides it as a platform: we deploy it on our bare-metal infrastructure inside Nepal, and applications built on top access it via a secure API. Our infrastructure provides the compute, VajraCore provides the AI orchestration, and the compliance application itself, the identity-verification and risk-scoring logic in this example, is built by the bank's own development team, a systems integrator, or through project work with us: not delivered as a packaged VajraCloudAI product. Each layer does what it's best at.
A question sophisticated investors and bank IT heads ask: if your GPUs are distributed across multiple sites, how do you handle workloads that need GPUs to work closely together? The answer depends on the workload, and the workloads matter.
Well-suited to distributed multi-site architecture
Inference means running an already-trained AI model to process a request: verifying a KYC document, screening a name against a sanctions list, flagging a suspicious transaction. Each request is independent. A GPU at Site A does not need to communicate with a GPU at Site B to complete its job. It simply receives the request, runs the model, and returns a result.
This is exactly the workload our banking customers need today. VajraCore routes each incoming request to whichever GPU is available across our distributed sites, presenting the whole distributed footprint as a single logical pool, handling load balancing automatically, and scaling capacity by adding more sites rather than concentrating everything in one location.
Managed through hub-and-spoke concentration
Training means teaching an AI model: adjusting its internal parameters based on data until it learns to recognize patterns. Large-scale training requires GPUs to exchange data with each other continuously, and latency between GPUs matters. Spreading GPUs across geographically separate sites introduces network latency that slows this communication and reduces training efficiency.
However, two things are important: first, our near-term banking workloads are inference, not training from scratch. Second, when training is needed (for example, a bank fine-tuning a fraud detection model on its own transaction data), the model sizes involved are far smaller than frontier LLMs, and manageable across a concentrated cluster at a single site.
KYC, AML, and transaction monitoring are inference workloads. Our first banking customers will see no constraint from the distributed architecture: their workloads are exactly what distributed inference is designed for. The training-hub constraint is a Phase 3 and Phase 4 consideration, not a Phase 1 or 2 blocker.
As banks eventually want to fine-tune models on their own data, the primary colocation site becomes the training hub. The secondary sites handle inference serving. This is a standard neocloud architecture: the same hub-and-spoke pattern used by established players globally, now applied to Nepal's multi-site colocation reality.
Full demo suite: PoC architecture docs, compliance dashboard mock, presenter scenario guide, and live AI-powered KYC/AML on seeded test bank customers.
How CBS data reaches the platform: new & existing customers.
GPU orchestration, model serving, lifecycle.
Flagged accounts, STR drafts, activity feed.
15-minute presenter script for live demos.
Run AI assessments · MongoDB-backed test bank.
Run ./dev.sh for setup steps. Use ./serve.sh (not python from project root) and ./start-backend.sh on port 8001.
Neoclouds are infrastructure businesses: they are evaluated on power cost, utilization rates, customer contract duration, and hardware depreciation schedules, not on monthly active users or viral growth. The return case is built on durable, high-switching-cost enterprise contracts and, ultimately, on the strategic value of the position to a larger acquirer.
Our capital model is deliberately asset-light for this category: we colocate bare metal in existing carrier-grade facilities rather than constructing a datacenter, removing the largest capital and timeline risk at the outset. We own everything from the rack up (compute, storage, orchestration) and plan to license VajraCore, a third-party platform, as the AI delivery layer on top.
Why we stage rather than raise all at once
We start with the cheapest possible validation and only spend more capital once each previous gate is proven. No phase is assumed: each is contingent on the one before it working.
Validate the VajraCore layer end-to-end on AWS before committing any hardware capital.
A 3-node hyper-converged micro-cluster, colocated, with a single GPU, proving the stack works end-to-end before any production commitment.
Convert early conversations into a paid or committed pilot, anchored by a regulated-sector customer, before scaling hardware further.
28 nodes across two colocation sites, totaling approximately 0.5MW of grid capacity, the core build this $5M raise funds.
Once 0.5MW is operating, scale further by distributing GPU capacity across additional sites, sized to what each site can sustain, unified by VajraCore.
*PoC run-cost estimate based on current pricing from one VajraCore platform provider under evaluation and pending final colocation quotes; figure represents current best estimate, not a contracted rate.
Beyond This Raise: Long-Term Vision
Our long-term goal is to build a regulatory and operational position in Nepal (and potentially adjacent emerging markets with similar data-localization dynamics) that becomes a strategic asset to a larger acquirer: a regional telecom group, sovereign-cloud platform, or systems integrator seeking an established, compliant foothold rather than building one from scratch. We see this as a more credible path to a large outcome than competing directly in the saturated US/EU compute market, where our regulatory moat would not apply. This is a long-term orientation, not a funded or costed phase of this raise.
No single colocation site in our current footprint can sustainably power and cool a concentrated multi-GPU deployment. Rather than force that load into one location, we spread GPU capacity across multiple sites (one or a few GPUs per site) matched to what each facility can actually sustain.
VajraCore's orchestration layer abstracts this physical distribution. To an application or end user, the distributed footprint is presented as a single logical compute pool, even though the underlying GPUs sit in different buildings.
What this does and doesn't solve
We'd rather show three honest scenarios and a real breakeven bar than one optimistic number. Two inputs below are sourced; the per-customer spend figure is our own estimate, clearly labeled.
$50,000/bank/yr
SAM (20 banks)$1.0M/yr
Power-only breakeven5.3 banks
% of total market26%
$100,000/bank/yr
SAM (20 banks)$2.0M/yr
Power-only breakeven2.6 banks
% of total market13%
$200,000/bank/yr
SAM (20 banks)$4.0M/yr
Power-only breakeven1.3 banks
% of total market7%
TAM beyond these 20 banks (public sector and telecom adjacencies) is directionally promising but not yet sized with sourced data, and is excluded from the figures above.
We're presenting our cost basis in two tiers: figures we can stand behind today, and figures that remain working estimates until contracts are signed. We'd rather show the gap honestly than round it away.
We intend to firm up the bottom two rows from the active bank pilot conversation and outstanding vendor RFQ responses before our next investor update.
We are not building our AI delivery layer from scratch. We plan to license VajraCore, a third-party platform for orchestration and inference delivery, sitting on top of infrastructure we design and operate ourselves.
We'd rather an investor hear this from us directly than discover it in diligence.
▸Hardware: Zero GPUs currently owned. The Phase 1 RFQ has been issued to hardware vendors; no purchase orders placed yet.
▸Colocation: In discussion with carrier-grade facility operators for rack space, power, and cooling. Terms not yet finalized.
▸Platform partner: Evaluating third-party AI orchestration platforms for the VajraCore layer. No vendor selected or contracted yet.
▸Customer: Early-stage conversations with a leading commercial bank in Nepal as a prospective pilot customer. No signed letter of intent yet.
▸Funding: A private equity investor has expressed interest in the thesis and is a potential source of both capital and pilot customer introductions. No capital committed yet.
▸Regulatory basis: Our data-localization thesis is directional and still being substantiated with specific legal citation. We are not yet representing this as a confirmed regulatory lockout.
This is an early-stage opportunity. We're sharing it at this stage of clarity because we believe the underlying thesis (a compliance-grade AI platform for Nepal's regulated institutions, built on genuine structural cost and policy advantages, entering via the banking sector) is strong even before every commercial term is locked down.
For qualified investors: detailed financial model, vendor RFQ responses, and pilot customer pipeline notes.
