Always-on payments
Transactions complete online, degraded, or fully offline. Hardware-signed transactions reconcile cleanly when the device reconnects. No held funds, no dropped transactions.
Ensure digital payments
never fail
Payments keep working when the network does not. Money moves phone to phone and can pass through several people before it ever touches a server. Built CBDC-first, and deployable for any UPI or banking application.
What multi-hop means
Money you receive offline is spendable again offline, straight away, and so is the money the person after you receives, whether the phones are Android or iPhone. That chain can run several deep before anything reaches a server. Every hop carries cryptographic proof of the hops before it, and when any device in the chain reconnects the whole chain reconstructs.
Programmable money that survives disconnection
The rules travel with the money. Category, expiry, spending limits, and geography are all evaluated on the device at the moment of transfer, and the constraint holds with the network gone.
Designed for national scale
Benchmarked at 12,000+ TPS on the offline path, matching UPI peak. Settlement is batched at reconciliation, which keeps real-time load off the core ledger.
Operational clarity
Cryptographic proof of every hop in every transaction. Audit-ready settlement, full reconciliation, precise attribution for any dispute or double-spend event.
Banks and CBDC teams
Your customers transact where connectivity does not reach, and the exposure is capped before it starts, at five hops and seven days by default. Every object reconciles against your ledger the moment a device in the chain reconnects, and each duplicate is detected and attributed to the device that made it.
The SDK sits inside your own app, under your own brand. The server side runs on whatever infrastructure you require, including your own, in your own region. Data residency here is configuration, not architecture.
Read moreRead less
Every hop is carried on the object itself. The chain is therefore evidence a receiving device can verify before accepting anything, rather than a record reconstructed at settlement.
Technology partners
Add offline to what you already sell into banks
Nomesma ships as an SDK, client side and server side. Offline goes into your product without changing it. It connects to an existing CBDC deployment or at the core banking layer, and the bank's app and brand stay its own.
Offline multi-hop is a capability your competitors are not bidding with, and one you do not have to build.
You choose how much of the device hardening you own. A white-label deployment ships with the device controls enabled, including root and jailbreak detection and anti-hooking. With the SDK that layer is yours, and we build it with you.
Venues and events
Run the closed loop you run today on the phones your attendees and your stalls already carry. No chip to encode per attendee, nothing to ship, no reader to rent per counter. A hardware line and a rental line come off every event, not once, along with the lead times and the bulk encoding behind them.
The next event is a configuration change. A new city or a new format runs the same deployment again.
How it works
Our offline-first architecture keeps programmable money resilient without sacrificing settlement integrity.
- 1
Step 1
Integrate once
We provide an SDK for the bank's mobile app and APIs at the Core Banking System (CBS) layer.
- 2
Step 2
Withdraw balance
Customers securely download an offline-capable balance to their device for in-person use.
- 3
Step 3
Transact offline, settle later
The receiving device checks the signature chain before it accepts anything, so the payment completes with no network in reach, and what waits for connectivity is settlement rather than the payment itself.
- 4
Step 4
Reconcile & settle
As soon as any party in the chain is online, our backend flags conflicts and checks for double-spend attempts. Ledger-level settlement occurs when the customer chooses to settle, analogous to depositing digital cash.
See it in action
A seamless experience across mobile and web, from offline payments to administrative oversight.
Mobile App
Wallet Dashboard
Balance, transactions & quick actions
Offline Payments
QR-based P2P transfers
Web Dashboard
User Dashboard
Full-featured web access for all users
Admin Console
Comprehensive oversight and management tools
Where this runs
The same rails, in three places where payments cannot afford to stop.
CBDC at banks and NBFCs
Deploy resilient, programmable retail CBDC rails without overloading the core ledger.
Events and venues
Closed-loop payments on phones, with the hardware line off the budget.
Disaster recovery and degraded connectivity
Essential payments keep moving through an outage, and reconcile once it ends.
Security first
Two questions decide whether offline money can be trusted: whether a device can create value out of nothing, and what happens when someone spends the same money twice.
Value is only ever minted server side. A device can receive it, hold it, and pass it on. It cannot create it. Forgery is therefore outside the threat model, which leaves double spending as the single problem to solve.
Signing happens on the device itself, inside hardware-rooted key storage. Every hop carries proof of the hops before it. An offline object either has a valid signature path back to issuance or it does not, and none of that is negotiated when a device syncs.
Double spending is detected, attributed, and bounded. Every duplicate is caught at reconciliation and traced to the exact device and its position in the chain, including collusion scenarios. One upload anywhere along the chain is enough to expose it. The exposure is capped before that, at five hops and seven days by default, configurable per deployment.
Read moreRead less
The hop cap and the expiry travel with the object itself. A receiving device checks chain length and expiry before accepting anything, and those two limits therefore hold whether or not the sender behaves honestly. A per-device balance cap is enforced differently, as no party but the local device can observe an offline balance. It holds on honest devices, and a manipulated device is identified at reconciliation rather than stopped at transfer.
Every device is identified and any device can be removed. Protected offline calls carry a token signed by the device's own key, which establishes the physical device behind a request and allows an administrator to ban it remotely.
A duplicate, once found, has a route to resolution. The deployment can report it to the regulator, or recover the amount directly where the operator holds the account, and the hop and expiry bounds cap how far it traveled before detection.
Device attestation proves which device made a request. However, it does not prove that the device or its operating system is unmodified. A compromised secure element is the hard case for every system in this category, ours included, and what the design does about it is cap the exposure before it happens and identify the duplicate afterwards.
Controls
- Root/jailbreak checks, anti-tamper, anti-hooking defenses
- Secure Element (SE) usage when available; robust fallback when not
- Cryptographic signatures and rolling counters on value movement
- Offline limits and risk thresholds set per deployment, with a five-hop cap and a seven-day expiry by default
- Hardware-rooted keys. Secure Enclave on iOS, StrongBox or the hardware-backed Keystore on Android. Where the device provides hardware backing, the key is generated inside it and never leaves the device.
Our guarantees
- Rapid attribution for offline double-spend attempts, including collusion scenarios
- We do not claim perfect offline prevention on compromised devices
Standards & alignment
- Built for offline payments that need no NFC and no extra hardware on the phone
- Nomesma is middleware, not a bank; features assist regulated entities
- MFA is hardware-backed. Authentication uses device-bound cryptographic credentials rather than transmissible secrets like OTPs.
- Patent application filed on the offline payment architecture, in India and under PCT. Priority August 2025.
About Nomesma
Our story
Nomesma Payments was founded in 2025. The underlying offline payment system was first prototyped in 2022 as a research project that reached the finals of RBI HaRBInger 2023. The company was spun out in 2025 after a year of additional development, and reached the finals of RBI HaRBInger 2025.
Digital payments shouldn't break when networks do. We build the middleware that lets CBDC teams, banks, and payment operators stay in control of settlement while users transact seamlessly online, degraded, or offline. CBDC is our primary deployment; the same infrastructure serves event payments, disaster recovery, and any high-stakes digital payment system.
Meet the team
Hardik Raheja
Founder
Hardik Raheja is the founder of Nomesma, and he designed the offline multi-hop protocol the product runs on. His official mentor through RBI HaRBInger 2025 was Lalitha Nataraj, CEO of BHIM. He is the sole inventor named on the patent application, filed in India and under PCT.
Jaden Furtado
Consultant — Cyber Security
Jaden is an OSWE-certified security professional and advises Nomesma on security review.
Let's connect
We work with CBDC and payments teams at banks, with technology partners who sell into them, and with operators looking at closed-loop payments for venues and events.
Email us
Compose emailBook a call
Schedule time and we will walk through where offline fits in what you already run.
Book a call