A US customer likes your product, likes your invoice, and then asks a question increasingly common in founder inboxes: "Can we just pay you in USDC instead of wiring the money?" For an Indian company that has spent months chasing a client's finance team for a $10,000 invoice, it can feel like a gift faster settlement, no correspondent-bank delays, no wire fees.
It isn't, legally, a simple one. The real question is not "is crypto legal in India" — it is narrower: does receiving stablecoins as consideration for an export of services satisfy India's foreign exchange law governing how cross-border payments must be received and realised? These are different questions, and conflating them is where most of the bad advice on this topic comes from. This article works through that narrower question under FEMA, 1999, RBI's export-realisation framework, and the overlapping PMLA/tax rules that shape how a stablecoin-based structure would actually be executed and defended.
Stablecoins are not "foreign exchange" under FEMA
FEMA regulates current and capital account transactions in "foreign exchange," while, since 2022 on the tax side, a separate regime governs "Virtual Digital Assets" (VDAs). Stablecoins like USDT and USDC sit only in the second category, and that placement is the source of the entire compliance problem.
Section 2(h) of FEMA defines "currency" through an inclusive list currency notes, postal notes, cheques, drafts, bills of exchange, promissory notes, credit cards, and other instruments RBI may notify and "foreign exchange" is defined by reference to "foreign currency." A stablecoin fits none of this: it is not issued by a government or central bank, and RBI has not notified it as a currency instrument. Established Indian law-firm commentary on virtual currencies under FEMA reaches the same conclusion because virtual currencies are not currencies under FEMA, they cannot be foreign currency, and therefore cannot be foreign exchange for FEMA purposes.
On the tax side, the Finance Act 2022 created a parallel classification: the VDA, defined broadly enough in Section 2(47A) of the Income-tax Act to capture any cryptographically-generated token wide enough to sweep in stablecoins despite their fiat peg. So a stablecoin is, simultaneously, not foreign exchange under FEMA and is a VDA (an asset) for tax purposes. FEMA governs how foreign exchange must enter India; a stablecoin doesn't fit that category at all, and instead falls into an asset class FEMA's export-realisation rules were never written to accommodate.
This is a genuine regulatory gap rather than a settled prohibition. Nothing in FEMA expressly bans an Indian resident from receiving a stablecoin. But nothing expressly permits it as a mode of export realisation either and export realisation is a specific, procedural obligation, not a general permission to receive value from abroad in any form the parties agree to.
Why the realisation framework matters more than the "legality" question
Under FEMA and RBI's directions on export of services, an Indian exporter must realise and repatriate the full export value within a prescribed period under RBI's new Foreign Exchange Management (Export and Import of Goods and Services) Regulations, 2026 (effective 1 October 2026), 15 months from the invoice date for services (18 months where realised in rupees). Critically, that realisation must occur through an Authorised Person ordinarily an AD Category-I bank — via permitted banking channels, evidenced by an FIRC or its electronic equivalent, e-FIRC, and reconciled against the export declaration.
None of that machinery contemplates a wallet-to-wallet transfer of a cryptographic token. There is no AD bank in the loop when USDT lands in a company's self-custody wallet or offshore exchange account, no SWIFT message, and no mechanism by which that receipt can be reported as export realisation. The exporter has been paid commercially. It has not been paid in a way the foreign exchange control framework recognises. "Stablecoins are dollar-pegged and economically equivalent to USD" is legally beside the point FEMA asks not whether value was transferred, but whether foreign exchange was received through the prescribed channel.
This risk is no longer hypothetical. In mid-2026, the Enforcement Directorate acted against several Bengaluru-based crypto-payment firms over roughly ₹2,500 crore alleged to have been routed abroad through stablecoin transfers without RBI authorisation action taken specifically under FEMA, on the basis that none of the entities was an authorised remittance channel. That is the clearest current signal of how regulators view direct stablecoin settlement.
Does converting the stablecoin to INR afterwards cure the problem?
Probably not, on a strict reading though the practical risk profile does change. The FEMA obligation attaches at the point of receipt. If a stablecoin is received into a wallet and only later sold on an Indian VDA exchange for rupees, that INR credit will typically be characterised as proceeds of a domestic VDA sale, not an inward remittance against an export invoice. It generates no FIRC/e-FIRC referencing the export contract and will not reconcile against the Export Declaration Form or RBI's export-tracking systems. Conversion changes the currency of the end result; it does not retroactively convert an unauthorised receipt into an authorised one.
That said, where the underlying export was genuine, disclosed, and fully accounted for, this is the kind of technical breach usually addressed through a compounding application to RBI (regularising contraventions on payment of a fee) rather than criminal exposure. It is a compliance failure to be managed and remediated not evidence of an illicit transaction. Founders should not conflate "we have a FEMA procedural exposure" with "we have done something illegal."
Three structures, three very different risk profiles
The compliance analysis changes sharply depending on where the stablecoin sits in the payment chain.
1. Direct stablecoin receipt. The foreign client pays USDT/USDC directly into the Indian company's wallet (self-custody or exchange account) the structure most exposed to FEMA risk. No AD bank is involved in the inward leg, no compliant FIRC/e-FIRC is generated, and the receipt itself may be viewed as foreign exchange obtained outside authorised channels, regardless of any later conversion to rupees.
2. Stablecoin-in, fiat-out payment processor. The foreign client pays a payment processor in stablecoins; that intermediary converts to fiat before the funds reach India, so what crosses the border is a conventional wire through an AD bank. The Indian exporter never receives a VDA at all and can obtain a standard FIRC/e-FIRC. FEMA exposure moves largely off the exporter's books and onto whether the intermediary is itself a lawful, licensed remittance channel a counterparty due-diligence question rather than the exporter's own compliance gap.
3. Ordinary fiat receipt, stablecoins bought separately afterwards. The foreign client wires USD through normal banking channels; the Indian company banks and reports the export proceeds as usual, and separately as an unrelated transaction buys USDT/USDC domestically with its own rupees for treasury purposes. No FEMA export-realisation issue arises: a compliant export, followed by a domestic VDA purchase under ordinary PMLA/KYC and tax rules.
The lesson: it is not the presence of a stablecoin anywhere in the relationship that creates FEMA risk, but whether a stablecoin crosses the Indian border in place of the foreign exchange FEMA requires for export realisation.
Worked examples
Example A — the SaaS invoice. An Indian SaaS company bills a US customer $10,000 annually. The customer, avoiding a wire fee, offers USDC instead. If the founder simply shares a wallet address, Structure 1 applies: the receipt falls outside FEMA's recognised channels, no FIRC is generated, and the export shows as unrealised however diligently other returns are filed. The safer answer is Structure 3 (ask for the wire despite the fee) or Structure 2 (accept stablecoin payment only via a processor that settles fiat into the Indian account).
Example B — the Web3 protocol company. An Indian entity provides smart-contract development to an offshore DAO or foundation that operates natively in stablecoins and has no conventional bank account. Structure 3 may genuinely be unavailable. This is where Structure 2 — a compliant, properly licensed stablecoin off-ramp settling fiat into India — earns its keep, and where routing invoicing through a properly capitalised overseas subsidiary (subject to ODI/OPI rules) can become commercially necessary rather than optional.
Example C — the freelancer-turned-founder. A solo developer, previously accepting USDT informally for freelance work, incorporates a company and keeps the same habit for its export contracts, assuming past practice means compliance. Scale changes the risk: banks ask harder questions about INR credited after a VDA sale, and larger volumes attract more AD-bank and potential ED attention than an individual's occasional receipts — precisely the pattern behind recent enforcement action against payment intermediaries.
The overlapping PMLA and tax layers
PMLA/FIU-IND. Since a March 2023 government notification, VDA-related activities — exchange between VDAs and fiat, exchange between VDAs, and transfer of VDAs — are treated as "financial activities" under the PMLA, bringing VDA service providers within the reporting-entity regime: KYC, record-keeping, and suspicious-transaction reporting to FIU-IND. As of FIU-IND's most recent reporting cycle, dozens of exchanges — mostly domestic, plus a handful offshore — have completed registration, and FIU-IND has separately acted against unregistered offshore exchanges serving Indian users. The practical implication: any VDA-to-fiat conversion should route through an FIU-registered entity. An unregistered offshore exchange compounds FEMA exposure with a separate PMLA gap.
Tax treatment. Where a stablecoin is received or held as a VDA, Section 115BBH taxes gains on transfer at a flat 30% (plus surcharge and cess), with no expense deduction beyond cost of acquisition and no loss set-off against other income. Section 194S layers on a 1% TDS obligation above the prescribed threshold. Where the FEMA and tax analyses intersect: if a stablecoin is consideration for a service, the company still owes ordinary business-income tax on the invoiced amount, in addition to any VDA-specific treatment on later appreciation or disposal. Booking only the eventual INR realised on conversion, rather than the invoiced income plus any separate VDA gain, is a common and avoidable error. Tax compliance under 115BBH/194S is a parallel obligation satisfying it does nothing to cure a FEMA export-realisation gap, or vice versa.
Overseas structures: exchanges, group companies, and ODI/OPI
Routing payments through an overseas group entity a US or Singapore subsidiary that invoices the client, banks conventionally, and remits funds to the Indian parent as a permitted intercompany payment is a genuine option for startups with the scale to justify it. But it substitutes one FEMA framework for another rather than avoiding FEMA altogether: funding the overseas entity itself triggers India's Overseas Direct Investment (ODI) or Overseas Portfolio Investment (OPI) rules, with their own reporting and structuring requirements. This is a legitimate answer for scaled businesses; it is generally disproportionate for a single $10,000 invoice.
What should Indian startups do?
Default to conventional banking rails for invoiced exports. Treat stablecoin settlement as the exception requiring specific structuring, not the default rail enforcement risk currently sits disproportionately on the receiving end.
If a client wants to pay in stablecoins, insist conversion happens before the funds cross into India. A compliant payment processor that receives stablecoins offshore and remits fiat through an AD bank (Structure 2) preserves the relationship without importing FEMA risk provided the processor's own licensing is diligenced.
Never treat "we'll convert to INR later" as a compliance fix. Receipt, not conversion, is what FEMA tests.
Keep treasury-driven VDA purchases entirely separate from export invoicing. Buy stablecoin exposure domestically, through an FIU-registered VDA service provider, with clean rupee funds after export proceeds are properly realised and reported.
If direct stablecoin receipts have already happened, get ahead of it. Engage FEMA counsel and a chartered accountant to assess exposure and, where appropriate, pursue voluntary RBI compounding rather than waiting for an AD bank or the ED to raise it first.
Watch the 1 October 2026 EXIM regulations. The consolidated Foreign Exchange Management (Export and Import of Goods and Services) Regulations, 2026 digitise realisation-tracking, making undocumented or non-bank receipts easier for RBI and AD banks to flag, not harder.
Separate three ledgers: the export invoice and its INR-equivalent business income, FEMA-compliant banking evidence (FIRC/e-FIRC), and any VDA transactions with their own 115BBH/194S trail. Conflating them is the most common source of exposure in this space.
None of this locks Indian startups out of the stablecoin economy legitimate structures exist for digital-dollar exposure, treasury diversification, or client accommodation. But the legality of holding or trading a VDA is a separate question from whether a payment structure satisfies FEMA's rules on receipt and realisation of export proceeds. Until RBI issues clearer stablecoin-specific guidance, the safer posture is to keep the stablecoin on one side of the India border and the rupees, received through a bank, on the other.
At Fathom Legal, we help startups, Web3 companies, and finance teams cut through that confusion and get to the question that does matter: does this specific payment structure satisfy FEMA's rules on receipt and realisation of export proceeds. If your business is navigating cross-border payments in a digital-asset world, this is the practical, no-nonsense guide you need before your next invoice goes out.
This article is for general informational purposes and does not constitute legal or tax advice. FEMA classification of stablecoins remains an evolving and, in material respects, unsettled area of Indian law; startups should seek transaction-specific advice from FEMA counsel and a chartered accountant before adopting any stablecoin-linked payment structure.