Trading in crypto assets on exchanges has become common, and many users execute large numbers of spot trades. Under Indian income‑tax law, these trades can fall within the rules for virtual digital assets (VDAs).
While the tax provision is short, applying it to exchange records and execution formats can raise practical questions during computation and reporting. This note summarises the statutory position for spot trades and highlights common record‑level issues that affect the computation of income, without going beyond what the law states.
What the Law Taxes: “Transfer” of a Virtual Digital Asset
The starting point is classification. A transaction becomes relevant for section 115BBH only if it involves:
- an asset that qualifies as a virtual digital asset under the Income‑tax Act, and
- a transfer of that asset as recognised under the Act.
Where a spot trade results in delivery of a crypto asset and is executed for consideration (whether in money or in another asset), the transaction may need to be evaluated under the transfer‑based charging framework of section 115BBH.
Key point: The law is applied to the legal nature of the transaction, not the trading interface or the product label used by an exchange.
How Income Is Computed Under Section 115BBH
Section 115BBH prescribes a special method for taxing income from VDA transfers. In simple terms, it requires a transaction‑wise computation built around three components:
(a) Full value of consideration
Income computation begins with identifying the consideration received for the transfer. Where consideration is monetary, this is usually easier to trace. Where consideration is non‑cash (for example, another digital asset), the computation still requires a value to be adopted for the consideration as recorded and supported.
(b) Cost of acquisition
The law restricts deductions. In general, only the cost of acquisition is permitted as a deduction for computing income from transfer of VDAs. This means transaction fees, platform charges, and similar expenses may not be deductible under the special regime, unless the law or notified guidance specifically allows otherwise.
(c) Loss restrictions
Loss rules for VDAs are restrictive. Even where a transfer results in a negative outcome, the ability to adjust that loss against other income streams is limited under the VDA framework.
Practical takeaway: Even when a user’s trading activity appears economically “flat” across multiple trades, the law still operates on each transfer event for computation and reporting.
Identifying the “Unit” Being Transferred (Acquisition Linkage)
Most exchange trade reports show disposals and acquisitions, but the income‑tax computation requires a defensible link between:
- the asset disposed, and
- the corresponding acquisition(s) that form the cost base.
The Act does not prescribe a single mandatory tracking convention in the text of section 115BBH itself. Therefore, record quality becomes central: the computation depends on whether acquisition history can be reliably reconstructed from:
- exchange trade logs,
- deposit/withdrawal records, and
- any internal ledger formats used by platforms.
Where records commonly become difficult
Record linkage tends to require extra care when:
- holdings are spread across multiple accounts or storage locations, or
- transaction histories are split across more than one platform, or
- the platform output summarises activity in a way that does not preserve acquisition‑level granularity.
Important: The tax rule remains transfer‑based; the challenge is assembling supporting data in a consistent manner.
Valuation Where Consideration Is Not in Fiat Currency
Many spot trades in crypto markets do not settle directly in INR. Consideration may be received in another digital asset. In such cases, computation under section 115BBH still requires that the transfer be expressed in a rupee value for tax reporting.
Why valuation can be sensitive
Exchange statements may show:
- a single combined line item for a trade,
- an INR‑equivalent value, and
- a timestamp.
However, platforms may differ in how they derive INR‑equivalent numbers (for example, by internal pricing logic, execution price, or consolidated reporting formats). The statute does not set out a platform‑by‑platform valuation rule. As a result, traceability becomes the key concept:
- the value used in computation should be capable of being supported from contemporaneous records.
Recommended practice: Tax reporting should be consistent with the taxpayer’s records and the values that can be substantiated through available documentation.
When a Single User Action Creates Multiple Transfer Events
On many platforms, what appears as one “trade” on the screen may be executed as multiple transfers in the background. For tax purposes, the relevant question is whether the records show:
- more than one transfer of a VDA, each supported by consideration, within the overall flow.
This matters because section 115BBH applies to income from the transfer of a VDA. If the execution flow results in multiple transfers, a computation may be required at each transfer stage based on available transaction data.
Key point: The tax treatment follows the presence of transfer events reflected in the records, not the user’s intent to treat the flow as one economic decision.
Bundled Execution Formats and Asset‑Level Cost Allocation
Some exchanges offer bundled purchase formats that acquire multiple crypto assets under a single instruction (for example, a pre‑set basket). From a tax perspective:
- the underlying assets remain separate VDAs, and
- future computation under section 115BBH will require acquisition cost information for each asset.
Where the practical issue arises
If the platform records show only a consolidated debit without an asset‑level allocation, then determining acquisition cost per asset may require further supporting documentation. Similarly, if the platform activity reflects internal changes to composition through entries that look like trades, those entries may need to be examined under the transfer framework.
Legal position: The statute taxes transfers of VDAs; it does not create a separate taxation category for bundled crypto products.
Negotiated Spot Transactions and Documentation Trails
Spot transfers can also occur through negotiated execution processes facilitated by platforms. In such cases, the trade may be settled and reflected in account statements as a net movement. For section 115BBH computation, the central requirement remains the same:
- identify the transfer,
- identify consideration, and
- support the value and acquisition cost through available records.
Where settlement statements summarise values, additional transaction documents (if they exist) can become part of the overall substantiation set.
Reporting and Record Readiness
Section 115BBH is computation‑driven. In practice, this means a taxpayer should be able to support:
- the list of transfer events treated as taxable under the VDA framework,
- the consideration value adopted for each transfer, and
- the acquisition cost used in computation.
Because exchange reporting formats are not uniform across platforms, taxpayers often need to preserve:
- trade history exports,
- timestamped transaction logs, and
- deposit/withdrawal ledgers that explain movement continuity.
This does not expand the statute; it reflects the general principle that tax positions should be supportable with records.
Conclusion
Section 115BBH sets out a special regime to tax income from the transfer of virtual digital assets. Spot trades on exchanges frequently fall within this regime because they can involve delivery‑based transfers for consideration.
The main challenges are typically operational: identifying transfer events in exchange records, linking disposals to acquisition history for cost, and supporting valuation where settlement is non‑cash. These issues arise from trading formats and reporting practices, not from a different legal rule. Until additional crypto‑specific guidance is notified, applying section 115BBH requires careful alignment between computation and documentary support.