Germany’s crypto tax rules just handed developers and tax software vendors a new engineering problem. According to reporting from CryptoTicker, the German Federal Ministry of Finance (Bundesministerium der Finanzen, BMF) applies a wallet-based assessment, known in German as “walletbezogene Betrachtung,” when it comes to calculating crypto gains under the First In, First Out (FIFO) method. The rule sits in Randnummer 62 of the BMF letter dated March 6, 2025, and it means every wallet and every exchange account a German taxpayer holds gets its own separate FIFO queue. Nothing gets pooled across accounts.
That single clarification is rippling through the small but growing industry of crypto tax calculators, portfolio trackers, and accounting APIs that German investors and their advisors rely on every filing season. For coding teams building or maintaining these tools, wallet-by-wallet FIFO is not a cosmetic tweak. It changes how transaction data has to be ingested, tagged, and queried, and it raises the stakes on API reliability, internal-transfer detection, and audit-trail design. This article breaks down what the rule actually says, why it matters for developers and tax-software vendors, and what the current landscape of German crypto tax tools looks like as a result.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What the BMF’s Wallet-Based FIFO Rule Actually Says
FIFO stands for “First in, First out.” In plain terms, when a taxpayer cannot or does not identify which specific coin or token they sold, the method assumes the earliest-acquired units of that same asset type are the ones that left the wallet first. Germany’s income tax law, specifically Section 23 Paragraph 1 Sentence 1 Number 2 Sentence 3 of the Einkommensteuergesetz (EStG), expressly authorizes FIFO for fungible foreign-currency holdings. It was not written with crypto assets in mind, but the BMF has extended the same logic to digital assets through its administrative guidance.
The part that is generating the most discussion right now is the wallet-based scope of that FIFO calculation. Per the BMF letter cited in the CryptoTicker report, each wallet and each exchange account functions as its own closed accounting pool. If someone holds Bitcoin on a hardware wallet, more Bitcoin on Kraken, and still more on Coinbase, the tax office does not let them average or merge the acquisition history across those three locations into a single FIFO sequence. Each one runs its own independent first-in-first-out queue, based only on the coins that have moved into and out of that specific wallet or account.
The guidance also requires consistency once a method is chosen. The approach selected for a wallet must generally be kept in place until every crypto asset of that trading designation held in that wallet has been fully sold off. A taxpayer can switch methods after a later acquisition, but they cannot flip back and forth within the same holding period just to produce a more favorable result on a given sale.
Why Software Vendors Can’t Just Average Everything Anymore
For years, the simplest technical shortcut in crypto tax software was to treat a user’s entire portfolio as one undifferentiated pool of coins, regardless of which exchange or wallet address they sat in. That shortcut no longer satisfies the wallet-based assessment described in the BMF’s guidance. A compliant FIFO engine now needs a data model that preserves the origin, destination, and full movement history of every unit of crypto, not just a running net balance.
That has direct implications for how tax platforms ingest data. CoinTracking, one of the longer-running German-market tools in this space, supports imports from more than 300 exchanges and wallets through a combination of API connections and CSV uploads, according to recent vendor documentation reviewed in this research. It calculates both FIFO and LIFO and generates reports formatted for more than 100 countries, alongside portfolio tracking across categories like mining, staking, and lending income. Blockpit, a Vienna-based provider with a strong footprint in German-speaking markets, documents three main import routes: read-only exchange APIs, public wallet addresses or keys, and CSV files as a fallback when neither of the first two is available. Koinly similarly advertises automated imports from more than 300 exchanges and wallets with a Germany-specific reporting workflow.
None of that import infrastructure is new. What is new, or at least newly emphasized, is the requirement that the resulting ledger keep each wallet’s FIFO queue isolated rather than quietly flattening it into a single portfolio-wide number. Internal transfers between a user’s own wallets are the trickiest part of that problem. If a tool mistakes a self-transfer for a taxable disposal, it can generate a materially wrong tax position; if it fails to track which wallet the transferred coins land in, it breaks the wallet-specific FIFO queue on the receiving end.
The Developer Checklist Behind a Compliant FIFO Pipeline
Engineers building or evaluating crypto tax infrastructure for the German market are effectively looking at a data-integrity problem dressed up as a tax-law problem. A handful of technical requirements fall directly out of the BMF’s wallet-based approach:
- Wallet and exchange-account identity mapping that stays stable even when a user renames an account or reconnects an API key
- Separate FIFO lot ledgers per wallet, rather than one global ledger with a wallet tag bolted on afterward
- Reliable internal-transfer detection so a coin moving from the user’s own exchange wallet to their own hardware wallet is not booked as a sale
- Read-only API key handling with scoped permissions, since several providers flag API access as the preferred, lowest-error-rate import method over manual CSV uploads
- Reconciliation routines that catch drift between an exchange’s reported balance and the on-chain or in-app balance the software has recorded
- Audit-ready, immutable transaction histories that can be handed to a Steuerberater (tax advisor) or produced on request during an audit
- Export formatting aligned to Germany’s Anlage SO tax form, since that is where private crypto disposals typically get reported
That last point about API key handling is not unique to crypto tax tools. Any developer wiring a third-party API into a financial workflow runs into the same question of how to store and scope credentials safely, a problem covered in detail in this site’s guide to scanning for leaked API keys with TruffleHog. The same discipline that keeps a coding assistant‘s API key out of a public repository applies just as directly to a read-only exchange API key sitting inside a tax platform’s import pipeline.
Historical Context: How Germany Got Here
Germany’s crypto tax framework has been built incrementally through a series of BMF administrative letters rather than a single piece of fresh legislation. The foundational guidance arrived years ago and established the basic principle that privately held crypto assets sold after a one-year holding period are generally tax-free for individual investors, while gains on assets sold within that window are taxable as other income under Section 22 EStG. The wallet-specific approach to cost-basis methods is not brand new either; it traces back through earlier BMF guidance before being reaffirmed and detailed further in the March 2025 letter now being cited in current reporting.
What has changed is the level of scrutiny tax offices and software vendors are putting on exactly how that wallet-based FIFO calculation should be documented, a point echoed in a 2026 explainer from Boersen-Parkett on the mechanics of FIFO for crypto holdings. The updated cooperation and record-keeping expectations referenced in current guidance apply from the 2025 assessment period onward, meaning the 2025 tax year, filed in the months ahead, is effectively the first full cycle where this level of wallet-by-wallet documentation is squarely in focus for both taxpayers and the software they use to prepare their filings.
This evolution mirrors a broader pattern seen across crypto-adjacent compliance work. Just as blockchain analytics firms have had to build increasingly granular tracing tools to follow funds through mixers and privacy pools, covered in this site’s reporting on Chainalysis tracing $82 billion in crypto laundering and on hackers shielding $3.9 million through Zcash’s shielded pool, tax software vendors are being pushed toward the same kind of transaction-level precision, just for compliance rather than investigation purposes.
Market Impact: A Small Software Category Under a Bigger Spotlight
The German crypto tax software market is not enormous compared to the broader fintech or accounting software space, but it sits at an unusually sensitive intersection of tax law, personal finance, and software reliability. A wallet-based FIFO rule that was previously treated as a secondary detail in product documentation is becoming a differentiator that vendors are starting to foreground in their marketing and support material, according to coverage from German-language outlets including Blockpit, Boersen-Parkett, and Rechner-Hub.
For a vendor like CoinTracking, which has operated in the German market for over a decade, the wallet-based model lines up closely with infrastructure it has already built. Newer entrants and multi-jurisdiction platforms, including Koinly and Waltio, face a tougher balancing act: they need an engine flexible enough to handle FIFO in Germany, different cost-basis rules in other jurisdictions such as the United States or France, and still keep per-wallet ledgers isolated everywhere FIFO applies. Waltio, in particular, has built its core product around French tax reporting requirements, so its German-market FIFO handling is more of an extension than a native design center.
That competitive pressure is likely to show up first in how fast each vendor ships wallet-isolation features and internal-transfer detection improvements, not in headline pricing. Crypto tax software has historically competed on breadth of exchange integrations and ease of CSV import; wallet-based FIFO compliance adds a new axis of competition built around data-model correctness rather than coverage alone.
Comparing the Main Crypto Tax Platforms Serving German Users
The table below summarizes publicly documented capabilities of several platforms active in or adjacent to the German market, based on vendor documentation and the reporting gathered for this article. Figures describing exchange and wallet integration counts come from current vendor materials; any detail not confirmed in sourcing is marked accordingly rather than estimated.
| Platform | Primary Market Focus | Import Methods | Cost-Basis Methods Supported | Germany-Specific Export |
|---|---|---|---|---|
| CoinTracking | German-market pioneer, global reach | API and CSV, 300+ exchanges/wallets | FIFO, LIFO | Yes, reports for 100+ countries including Germany |
| Blockpit | Austria-based, European tax rules | Read-only API, public wallet address, CSV | FIFO (Germany default) | Yes, Anlage SO-oriented workflow |
| Koinly | Multi-jurisdiction, global | API and CSV, 300+ exchanges/wallets | FIFO and other jurisdiction-dependent methods | Yes, Germany-oriented reporting workflow |
| Waltio | France-focused, expanding in Europe | API and CSV | Jurisdiction-dependent | Limited; not natively built for Germany |
The FIFO Math: A Simplified Example
To see why wallet isolation changes outcomes, consider a simplified scenario involving two wallets rather than one pooled portfolio. The numbers below are illustrative only, built to demonstrate the mechanics of wallet-based FIFO rather than to represent any real transaction or tax filing.
| Step | Wallet A Holdings | Wallet B Holdings | Pooled (Not Permitted) Result | Wallet-Based (Required) Result |
|---|---|---|---|---|
| 1. Initial buy | 1.0 BTC acquired first | No holdings yet | Combined queue: 1.0 BTC (Wallet A) | Wallet A queue: 1.0 BTC |
| 2. Second buy | No new buy | 1.0 BTC acquired later, different price | Combined queue: 1.0 BTC (A), 1.0 BTC (B) | Wallet B queue: 1.0 BTC (separate from A) |
| 3. Sell from Wallet B only | Unaffected | 0.5 BTC sold | Would draw from earliest unit in combined queue (Wallet A’s coin) | Must draw only from Wallet B’s own FIFO queue |
| 4. Resulting cost basis | Unaffected | Based on Wallet B’s own acquisition price | Incorrect: would use Wallet A’s acquisition price | Correct: uses Wallet B’s acquisition price only |
The practical upshot is that a sale executed on one exchange cannot borrow a more favorable (or less favorable) acquisition price from coins sitting untouched in a separate wallet. Each wallet has to answer for its own history.
What the BMF Guidance Says, in the Agency’s Own Framing
The BMF’s administrative letter dated March 6, 2025 establishes the wallet-specific view as the operative standard for applying simplification methods like FIFO to crypto-asset disposals, a position the ministry had already signaled in earlier guidance issued in May 2022. The letter also makes clear that FIFO functions as a simplification tool for determining which units are treated as sold first when a taxpayer has not identified specific coins, and that the chosen approach for a given wallet generally has to be kept in place until all holdings of that type in that wallet are gone. Tami MÃķnnig, a tax professional who writes publicly about German crypto taxation, has described the underlying logic in similar terms: the FIFO method is used at the point of sale to work out which acquisition cost applies to the gain, and whether the one-year holding period has already been exceeded so that no taxable event applies at all. That framing underscores why the wallet a sale originates from, not just the asset type, determines the applicable acquisition cost under German rules.
What Remains Unconfirmed
Several details that would normally round out a story like this are not yet established in available reporting and should not be treated as fact. There is no confirmed figure for how many German taxpayers or crypto holders are directly affected by the wallet-based clarification, no confirmed tax revenue impact, and no confirmed statement from a specific exchange or wallet provider about how it is adjusting its own reporting tools in response. Coverage to date, including the CryptoTicker report that first flagged the Randnummer 62 detail, does not identify a named BMF spokesperson making an on-record statement beyond the text of the administrative letter itself. Readers should treat any number not tied to a named outlet or the BMF letter directly as provisional.
What This Means for Coding Teams Building Tax Tools
For teams maintaining crypto tax or portfolio software that serves German users, the wallet-based FIFO rule is a reminder that tax-adjacent fintech code carries legal weight that ordinary SaaS features don’t. A bug in a FIFO lot-matching routine is not just a user-experience problem, it is a potential misstatement on someone’s tax return. That raises the bar for test coverage, especially around edge cases like partial wallet transfers, re-imports after API key rotation, and historical backfills when a user connects a new exchange years after they started trading.
It also puts renewed emphasis on how these platforms integrate with the exchanges and wallets they pull data from. Teams evaluating whether to build custom API integrations in-house or lean on existing aggregator SDKs face a similar build-versus-buy decision to the one developers weigh when wiring up any third-party API key, a workflow walked through in this site’s guides to setting up API key access for DeepSeek’s V4.1 Flash model and OpenAI’s GPT-6.1 Sol API. The underlying lesson carries over directly: scoped, read-only credentials and careful key rotation matter just as much when the API in question touches someone’s exchange balance as when it touches an AI model.
There is also a data-governance angle that is easy to overlook. Crypto tax platforms are, functionally, financial record-keeping systems, and the same questions that come up in enterprise data governance, such as where sensitive records live, how long they are retained, and who can access them, apply here too. This site’s comparison of data governance, DSPM, and DLP approaches is written for a broader enterprise audience, but the underlying principle of knowing exactly where sensitive financial data sits and how it moves is just as relevant to a crypto tax vendor handling wallet-level transaction histories for tens of thousands of users.
Security Considerations for API-Driven Tax Pipelines
Wallet-based FIFO compliance depends on accurate, complete transaction data, and that data increasingly arrives through read-only exchange APIs rather than manual CSV uploads, per vendor documentation from Blockpit and others. That shift brings security considerations that sit squarely in the coding-tools and cybersecurity space. A read-only API key is lower-risk than a trading-enabled key, but it still exposes a complete transaction history if leaked, and that history is exactly the kind of sensitive financial data that has made crypto platforms a repeated target.
Recent incidents elsewhere in the crypto industry underline why that matters. This site’s coverage of a crypto casino breach in the report on the Duelbits hack that resulted in roughly $7 million in losses, and a separate report on a law enforcement officer’s case tied to a breach affecting 173 tenants, both illustrate how quickly exposed credentials or compromised third-party integrations can turn into direct financial losses. Tax software vendors handling read-only exchange API keys at scale are not immune to the same category of risk, even though the keys themselves are not meant to authorize withdrawals.
Predictions: Where Wallet-Based FIFO Compliance Goes Next
Based on the current trajectory of BMF guidance and vendor responses, a few outcomes look reasonably likely over the next one to two filing cycles, though none of these should be read as confirmed facts:
- Vendors serving the German market are likely to foreground wallet-isolation and internal-transfer detection more prominently in product marketing, since it has become a visible compliance differentiator rather than a background feature.
- Expect more German-language explainer content from tax advisors and software vendors alike walking taxpayers through exactly how per-wallet FIFO changes their expected tax position compared to a pooled calculation.
- Multi-jurisdiction platforms will likely invest further in configurable, per-jurisdiction cost-basis engines so the same transaction history can be run through FIFO for Germany and a different method where another country’s rules require it.
- Scrutiny of API-based data imports, including key scoping and rotation practices, is likely to increase as more of the import volume shifts away from manual CSV uploads.
- Further BMF clarifications or follow-up guidance addressing edge cases, such as staking rewards split across wallets or DeFi positions that move between protocols, would not be surprising given the pace of the ministry’s prior letters on crypto taxation.
Frequently Asked Questions
What does “wallet-based assessment” mean for German crypto taxes?
It means the FIFO calculation used to determine which crypto units are treated as sold first is applied separately to each individual wallet or exchange account, rather than pooling all of a taxpayer’s holdings into one combined sequence.
Where does this rule come from?
It is described in Randnummer 62 of a BMF letter dated March 6, 2025, according to reporting from CryptoTicker, building on an approach the ministry had already outlined in earlier administrative guidance.
Can I combine FIFO across all my wallets to get a better tax result?
No. Each wallet and exchange account runs its own independent FIFO queue based only on the coins that moved into and out of that specific wallet.
Can I switch between FIFO and another method for the same wallet?
The method chosen for a wallet generally has to be kept in place until all crypto assets of that trading designation in that wallet have been sold. A change is possible after a later acquisition, but not as a way to cherry-pick results mid-holding.
Do crypto tax software tools like CoinTracking or Blockpit already handle this correctly?
Current vendor documentation describes support for per-wallet tracking, FIFO calculations, and API-based imports, but the exact degree of real-world compliance with the newest BMF framing has not been independently verified in available reporting.
Does this affect crypto held for more than a year?
Germany’s general private-sale rule still exempts crypto gains from tax if the asset was held for more than one year before being sold. The wallet-based FIFO rule governs how acquisition cost and holding period are calculated, not whether the one-year exemption itself exists.
Is this rule specific to Bitcoin, or does it apply to all crypto assets?
The BMF’s FIFO guidance is framed around crypto assets generally, not a single coin, and applies per trading designation within each wallet.
What should developers building tax software prioritize first?
Based on the requirements implied by the wallet-based rule, the highest-priority items are accurate wallet identity mapping, isolated per-wallet FIFO ledgers, reliable internal-transfer detection, and secure handling of read-only exchange API keys.
