Skip to content

Disconnected Financial Runtime

Intelligence and value.Beyond connectivity.

TAMVEL is building runtime infrastructure that lets financial applications keep permitted intelligence and bounded value flows working when the cloud is out of reach — and reconcile when it returns.

Explore the RuntimeJoin the Pilot

Network Offline

Runtime Local execution

Illustration: a network of connections fades away while the TAMVEL runtime at its centre keeps executing local work, then reconnects and reconciles.

Narrated overview · 2 minutes

Meet TAMVEL

A short, narrated walk through the runtime — with captions, a full transcript, and pause, mute and replay controls. Nothing plays until you press play.

Captions and transcript available. Download captions (WebVTT).

01The problem

Connectivity is a condition, not a guarantee.

Financial software is increasingly intelligent — and increasingly dependent on a live connection to be intelligent at all. When the connection goes, capability goes with it.
Device and cloud. Network: Connected. Risk check: Cloud. Payment: Authorized. Assistant: Cloud model.CLOUD SERVICESCONNECTED
Cloud path
  • Risk checkCloud
  • PaymentAuthorized
  • AssistantCloud model

With a network, the cloud does the work.

Risk models, assistants and payment authorization all sit a request away. When connectivity is good, that is the right design — and TAMVEL keeps it.

02The TAMVEL Runtime

One runtime. Every condition.

An SDK-level runtime that sits between your application and its compute. It routes intelligence to where it can run, keeps value operations inside an isolated financial module, and reconciles everything when the network comes back.

Select any component to inspect it.

ISOLATED FINANCIAL BOUNDARYApplicationYour productTAMVEL RuntimePolicy · capability · routingLocalAvailableEdge (reserved)Reserved · not in V1CloudReachableValue ModuleStandard modeReconciliationSettling

03Offline AI

Intelligence that doesn’t wait for a signal.

Selected models run on the device when the cloud is unavailable — or when sending the data would be inappropriate. When a task needs more than the device can offer, the runtime escalates to the cloud, or queues the work until it can.
Task
Connectivity
Illustrative policy

Placement

Local

Runs on the device first. If the local model’s confidence falls below the application’s threshold, the runtime escalates to the cloud.

Deciding factors

  • Keeps sensitive data on the device+2.7
  • No network round-trip+1.9
  • No marginal cloud cost+0.5

04Green, cost-aware execution

The right place to run — including later.

For work that is suitable, the runtime weighs privacy, capability, latency, cost, energy, carbon and connectivity, then places it locally, in the cloud, or defers it. An edge placement is reserved in the architecture and is not part of V1. Local is not automatically greener: a small device running a large model can use more energy than an efficient data centre on a clean grid. The runtime decides case by case.
50
BasicHighest
40
PublicHighly sensitive
60
Entry-levelFlagship
50
Can waitInstant
40
LowHigh
30
Plugged inLow battery
40
CleanCarbon-heavy
Connectivity

Local

Selected

score 2.4

Edge

reserved · not in V1

Cloud

score -1.1

Defer

score -0.6

Why local

  • Keeps sensitive data on the device+1.2
  • No network round-trip+1.0
  • No marginal cloud cost+0.5
Illustrative model

A simplified teaching model of how placement decisions trade off. The production policy engine is in development; its inputs, weights and measurements will be published with methodology before any efficiency or emissions claims are made.

05Offline value

Bounded value, honestly reconciled.

TAMVEL is researching infrastructure that lets compatible wallets and financial applications work with bounded, pre-authorized digital value — including stablecoins — during temporary connectivity loss, then reconcile when connectivity returns.
Network · OnlineLedger · Reachable

Offline allowance (illustrative)

200.00 / 200.00

Payer device

secure value module

local channel
Payee device

secure value module

Signed records

No offline records yet.

What this is

  • Software infrastructure for compatible wallets and financial applications.
  • Bounded, pre-authorized value with limits set by the application’s financial partners.
  • Signed records with replay controls, reconciled against authoritative systems.

What this is not

  • Not a consumer wallet, and TAMVEL does not intend to issue a stablecoin.
  • Not offline blockchain consensus, and not unlimited offline finality.
  • Not risk-free: conflicting or excess offline claims can occur on a compromised device; partner liability and recipient provisional exposure are bounded, and conflicts are surfaced during reconciliation.

How TAMVEL bounds double-spend

A compromised payer device can sign more than it is allowed to spend, and we do not claim otherwise. What TAMVEL bounds is where that overspend can land.

Who can lose what when a payer over-signs offline
PartyBound
Financial partnerNever pays beyond the hold it placed when it issued the allowance. Reconciliation accepts at most the allowance amount, in the order claims arrive; the rest are refused.
PayerDebited at most the allowance amount, however many payments the device signed.
RecipientCan be left with a provisional record that is later refused. Each recipient device is capped by the partner’s per-payment and total provisional limits, and provisional value is never spendable.
TAMVELHolds no funds and never signs or sends a transfer.

Conflicting signatures from one device are kept as evidence for the partner’s risk process, and a partner can choose to freeze a key that provably signed two conflicting payments. This is sandbox research on a test network. The full exposure model, with a test for each bound, is available to prospective pilot partners on request.

Research stage

06Security

Designed to fail closed, not open.

Disconnected operation raises the bar for security, not lowers it. These are the principles the runtime is being built on.

  • Hardware-backed keys

    Signing keys for value operations are designed to live in the device’s hardware-backed keystore or secure element where available, and are never exported.

  • Bounded exposure

    Partner liability is capped at the held allowance, while policy limits cap the provisional exposure a recipient may accept. Conflicting or excess claims are resolved during reconciliation.

  • Replay protection

    Every signed record is designed to carry a monotonic counter and binding to its parties, so replayed records can be rejected and counter reuse or conflicting offline activity can be detected during reconciliation.

  • Tamper resistance

    Offline-value capability is enabled only after required device and hardware-backed key checks are verified while online. During an outage, the runtime relies on provisioned credentials and local consistency checks, and fails closed when required state is invalid.

  • Auditability

    Decisions and value operations produce structured, signed logs that partners can inspect — including why intelligence ran where it ran.

  • Reconciliation

    Offline activity is provisional until settled against authoritative systems. Conflicts are surfaced to the partner’s risk process, never silently resolved.

  • Least privilege

    Each module gets only the capabilities it needs. The intelligence layer cannot authorize payments; the value module cannot read model inputs.

  • Principles, not certifications

    TAMVEL holds no security certifications today. Independent assessments will be published as they are completed. Report a vulnerability.

07Developers

Android first. Policy as code.

A Kotlin SDK that fits the way mobile teams already build: declare what may run offline, call intelligence and value through typed APIs, and receive a reconciliation report when the network returns.

App.kt

// PROTOTYPE API — illustrative only. Names and shapes will change.val runtime = Tamvel.initialize(context) {    policy = Policy.fromAsset("tamvel-policy.json")    connectivity = ConnectivityMonitor.system()    telemetry = Telemetry.localOnly()}

08Who it is for

Built for the teams that move money.

TAMVEL is infrastructure. It ships inside other companies’ products — never as a consumer app of its own.
  • 01WalletsKeep core flows usable on trains, in basements and across patchy regions.
  • 02FintechsAdd on-device intelligence without routing every decision through the cloud.
  • 03NeobanksDegrade gracefully instead of failing hard when the network does.
  • 04Remittance platformsServe corridors where connectivity is intermittent by default.
  • 05Payment companiesExplore bounded offline acceptance with explicit reconciliation.
  • 06BanksEvaluate resilient, policy-governed execution for customer channels.
  • 07Stablecoin infrastructure providersResearch how bounded, pre-authorized value can survive short outages.

09Pilot

Build it with us.

We are inviting a small number of design partners — wallets, fintechs, banks and payment and stablecoin infrastructure teams — to shape the runtime before general availability.

  1. 01

    Scope

    A short conversation about the flows you need to keep working offline, and the constraints of your partners.

  2. 02

    Design

    We map policies — what may run locally, what must wait, what is never allowed — against your architecture.

  3. 03

    Prototype

    Early SDK access for a bounded evaluation in a non-production environment.

Participation is exploratory and non-binding. TAMVEL is an early-stage company; the pilot does not involve moving real customer funds.

Protected by Cloudflare Turnstile. No marketing lists.

10Founder

Portrait of Rohit Kashyap

Rohit Kashyap

Founder, TAMVEL · Founder & CEO, Zyaku

Rohit Kashyap founded TAMVEL to keep financial apps working when the network doesn’t. He is also the founder and CEO of Zyaku, an offline-first platform for creators and independent journalists. Across both companies, his focus is technology that keeps working for people when the internet doesn’t.