Germany is one of the most demanding jurisdictions in the EU for digital-asset compliance. Any business offering crypto-asset services to German residents or operating from German soil must maintain a transaction monitoring program that satisfies BaFin (the Bundesanstalt für Finanzdienstleistungsaufsicht) and, since the full application of MiCA (the EU Markets in Crypto-Assets Regulation), the converging European standard enforced by ESMA and national competent authorities. Getting that program wrong does not produce a warning letter. It produces frozen correspondent-bank rails, a licence suspension and, where the gap is systemic, criminal referrals. This page maps the regulatory basis, the practical build process, the cross-border pressure points and the decision threshold at which outside counsel adds measurable value.
What triggers transaction monitoring obligations in Germany?
The obligation to monitor transactions arises from two converging regimes: the German Anti-Money Laundering Act (Geldwäschegesetz, or GwG) and the MiCA supervisory framework, both administered by BaFin for entities holding a CASP authorisation (crypto-asset service provider authorisation) or operating under transitional provisions. The GwG imposes risk-based monitoring on all obliged entities, a category that expressly covers crypto-custodians, exchanges and transfer services. Under MiCA, ESMA and the relevant national competent authority – BaFin for German-domiciled entities – expect the monitoring program to align with the technical standards that ESMA publishes for CASPs across the EU/EEA.
The practical trigger is simpler: if your business holds, transfers, exchanges or provides custody of digital assets for customers who are natural or legal persons, and you touch German jurisdiction – whether through a German entity, a German IBAN, or a customer base that includes German residents – you are within BaFin's supervisory perimeter. The cross-border angle matters immediately. A business incorporated in Lithuania or Malta that passports its MiCA CASP authorisation into Germany still falls under BaFin's host-state oversight for conduct in the German market, including the adequacy of its AML controls.
Two structural facts define scope. First, the Travel Rule (the obligation to pass originator and beneficiary data alongside a transfer, derived from FATF Recommendation 15) applies to virtual-asset transfers above the applicable threshold; BaFin expects the monitoring system to detect and flag Travel Rule failures in real time. Second, BaFin's supervisory expectations for crypto firms are materially aligned with those applied to traditional financial institutions – the "risk-based approach" language of the GwG carries the same interpretive weight here as in banking.
What are the core components of a compliant monitoring program under BaFin?
A compliant transaction monitoring program under the GwG and MiCA has five structural components, each of which BaFin examines during a supervisory review or an on-site inspection.
The first is a documented business risk assessment. This is not a checklist. It is a written analysis of the specific products, customer segments, geographies and delivery channels the business operates, mapped against money-laundering and terrorist-financing typologies relevant to crypto. BaFin expects the assessment to be updated when the business model changes – a new product launch, an expansion into a new market, or a shift in the customer profile are each triggering events. In our practice, firms that enter a BaFin review with a stale or template-copy risk assessment face the sharpest scrutiny.
The second component is KYC framework integrity – customer due diligence procedures that classify customers by risk tier and apply enhanced due diligence to high-risk relationships. For a crypto business, "high risk" includes customers in FATF grey-list jurisdictions, customers conducting large or unusual on-chain transactions, and politically exposed persons. The third component is the monitoring engine itself: rule-based and, increasingly, behaviorally adaptive systems that flag anomalous patterns across on-chain and off-chain activity. BaFin does not mandate a specific vendor, but it expects the chosen system to be calibrated to the firm's actual customer base – a calibration that must be documented and periodically tested.
The fourth component is the Money Laundering Reporting Officer (MLRO) function. The GwG requires that a natural person hold this role, that they have the seniority and access to escalate findings to management and BaFin, and that they be approved or at least notified to the regulator. Outsourcing the MLRO role to a third-party provider is permissible under the GwG in certain structural conditions, but BaFin scrutinizes such arrangements closely. The fifth component is a record-keeping and reporting architecture that supports Suspicious Activity Reports (SARs) to the German Financial Intelligence Unit (Zentralstelle für Finanztransaktionsuntersuchungen, FIU) within the statutory deadlines.
For a scoped assessment of your monitoring program against BaFin's current expectations, contact OBOLUS at info@oboluslaw.com. The process above describes the standard build. Your entity structure, user base and banking stack change the analysis. Map your options.
How does the Travel Rule interact with the monitoring program?
The Travel Rule sits inside the monitoring architecture, not alongside it. Under the applicable EU wire-transfer and transfer-of-funds rules that ESMA supervises under MiCA, a CASP that originates or receives a virtual-asset transfer must collect, verify and transmit originator and beneficiary information. The monitoring system must confirm that this data accompanies each qualifying transfer and flag any transfer where the data is absent, incomplete or inconsistent.
This creates a practical build challenge. Most legacy monitoring tools were designed for fiat payment flows. Virtual-asset transfers involve on-chain transaction hashes, multiple custody layers and, in many cases, counterparty VASPs operating under different Travel Rule protocols – some using IVMS 101 data formats, others using proprietary messaging. The monitoring system must be able to ingest on-chain data, match it against the off-chain customer record, and detect Travel Rule failures before the transaction settles or – where settlement is irreversible – flag the failure for post-hoc remediation.
BaFin's supervisory posture on the Travel Rule has tightened. Operators we advise have seen BaFin request detailed evidence of how Travel Rule compliance is operationalized for transfers to unhosted wallets, which carry elevated risk under the applicable guidance. The expectation is not simply that the firm has a policy. The expectation is that the monitoring system produces an auditable log showing compliance decision-making at the transaction level.
The cross-border reality: Germany plus EU passporting
For a business using a German CASP authorisation to passport across the EU/EEA, the transaction monitoring program must scale to the full passport perimeter. BaFin authorises the entity and leads the prudential and AML supervision. But a customer in France, a correspondent bank in the Netherlands and a custody layer in Ireland each introduce host-state regulatory expectations and local FIU reporting obligations that a single German-configured system may not satisfy without adjustment.
We have seen operators build a system that is entirely BaFin-compliant and then discover that their French user base triggers TRACFIN reporting requirements that differ from the German FIU process. The Travel Rule data threshold that applies in Germany – or more precisely, the EU-wide threshold under the Transfer of Funds Regulation as applied by ESMA – may interact differently with the wire-transfer rules of a non-EU jurisdiction where the counterparty VASP is located. Monitoring program design must therefore account for the full transaction flow, not only the leg that touches German infrastructure.
The banking layer adds further complexity. German correspondent banks have high AML sensitivity to crypto clients. A crypto firm whose transaction monitoring program does not produce clean, auditable outputs risks losing its euro-IBAN access. In our cross-border practice, we regularly advise firms to treat the bank's AML questionnaire as a second supervisory review – one where the standard for documentation is effectively the same as BaFin's, but the enforcement mechanism is account closure rather than a formal sanction.
Building the program: process and timeline
A transaction monitoring setup for a German-regulated entity proceeds in five stages. The order matters because BaFin expects the risk assessment to precede the system design – a firm that configures its monitoring engine before completing the risk assessment will be asked to demonstrate that the two documents are consistent.
Stage one is the business risk assessment – a written, board-approved analysis of the firm's inherent AML/CFT risk profile. For a new entrant, this typically takes several weeks, depending on the complexity of the product suite and the number of geographies served. Stage two is KYC-framework design: mapping customer-risk tiers, defining the enhanced due diligence triggers and building the onboarding workflow that feeds the monitoring system with clean customer data. Stage three is system selection and calibration: choosing a monitoring vendor or building in-house rules, configuring the alert thresholds to the actual customer behavior baseline, and documenting the calibration rationale. Stage four is Travel Rule integration: connecting the monitoring system to the firm's Travel Rule solution, testing the data-match logic and confirming the unhosted-wallet policy. Stage five is MLRO appointment and SAR infrastructure: confirming the MLRO's remit, building the SAR drafting and escalation workflow, and establishing the FIU reporting channel.
End-to-end, a build from scratch for a firm with a moderately complex product suite and a multi-jurisdictional customer base typically requires a number of months. Firms that engage counsel at stage one – before system selection – avoid the retrofit costs that arise when the risk assessment and the monitoring configuration do not align. That misalignment is the single most common cause of BaFin findings in mid-size crypto firms, in our experience.
If a prior application stalled or a monitoring audit raised findings, a structured review can surface the gap and the path to remediation. Write to OBOLUS at info@oboluslaw.com or map your options here.
Micro-matter: monitoring gap identified on EU expansion
In a recent cross-border matter, a payments business holding a CASP authorisation in one EU member state sought to expand into Germany and began enrolling German retail customers before completing its Travel Rule integration for transfers involving German IBANs. We were engaged after the firm received a BaFin information request. We conducted a gap analysis against the GwG requirements and the applicable ESMA technical standards, identified the three specific control failures – incomplete originator-data collection, untested alert-calibration documentation and an MLRO appointment letter that had not been filed with the home-state regulator – and structured a remediation plan that the firm submitted within the regulator's response window. The monitoring program was rebuilt with Travel Rule integration in place, the MLRO filing was completed and the BaFin inquiry closed at the information-request stage without a formal enforcement referral.
What are the most common mistakes in German crypto AML setup?
Four patterns account for the majority of BaFin findings in crypto AML reviews. First, a risk assessment that is generic – copied from a template or from another jurisdiction's version – rather than calibrated to the firm's actual product and customer profile. BaFin reviewers identify this quickly, and a generic assessment undermines the credibility of every downstream control.
Second, monitoring-rule thresholds that are set at the maximum permitted under the regime, without documented justification. A high threshold means fewer alerts, which looks efficient. But if a threshold is not justified by the firm's actual risk data, BaFin treats it as evidence that the program is designed to minimize compliance friction rather than detect risk. The documentation of calibration decisions is as important as the decisions themselves.
Third, Travel Rule solutions that handle outbound transfers but fail on inbound transfers from VASPs using different messaging protocols. This is a technical failure with legal consequences: an inbound transfer without compliant originator data is a Travel Rule breach, regardless of which party sent the defective message. The monitoring system must flag it, and the firm must have a documented procedure for handling it.
Fourth – and this is increasingly significant as BaFin aligns with ESMA – a monitoring program that was built to the prior German VASP regime and has not been updated to the MiCA CASP standard. The two regimes overlap substantially, but MiCA introduces additional customer-disclosure and record-keeping requirements that feed back into the monitoring architecture. A firm operating on a pre-MiCA build should treat that as an immediate remediation item.
A common assumption in the market is that an offshore registration – a BVI VASP registration, for example, or a Cayman registration – provides a workable compliance base for serving German customers. It does not. BaFin's jurisdiction is triggered by the customer relationship and the market contact, not only by the entity's place of incorporation. Serving German customers through an unregistered offshore structure while relying on that structure's AML program to satisfy German regulatory expectations is an exposure the business cannot afford. The enforcement consequence is not a fine calibrated to the offshore entity. It is a market-access prohibition in Germany and, under MiCA's passporting architecture, across the EU.
Decision matrix: which operator profile needs what
Different operator profiles face different monitoring build requirements. A newly authorised German CASP with a retail exchange product and a domestic customer base needs a full five-stage build from the ground up, with Travel Rule integration as a launch-day requirement. The key risk at this stage is timeline compression – the temptation to go live before the calibration documentation is complete. BaFin's supervisory calendar for new authorisations typically includes an early compliance check; a monitoring program that is live but undocumented fails that check.
A passporting CASP using a non-German EU authorisation to serve German customers needs a host-state gap analysis against BaFin's specific supervisory expectations and the GwG. The monitoring program may already satisfy the home-state requirements, but German-specific expectations – particularly around unhosted-wallet risk and FIU reporting – may require a configuration update rather than a full rebuild. The timeline for this profile is shorter, but the risk of underestimating the gap is high.
A crypto firm with a significant institutional customer base – funds, family offices, corporate treasuries – faces a different calibration challenge. Institutional customers present lower typical-transaction risk but higher single-transaction size, meaning the monitoring thresholds must be set to detect anomalous volume patterns rather than individual small-transaction anomalies. The enhanced due diligence logic for institutional onboarding must also feed the monitoring system with sufficient customer-profile data to make alert decisions meaningful.
A firm operating in multiple EU jurisdictions through a single German CASP authorisation needs a monitoring architecture that can produce jurisdiction-specific reporting outputs. A single alert queue is insufficient if the downstream SAR process requires differentiated routing to the German FIU and to host-state equivalents.
Related at OBOLUS
Related at OBOLUS
- AML and Travel Rule compliance for digital-asset businesses – our full practice scope across 70+ jurisdictions, from program design to regulator engagement.
- VASP business risk assessment: the disputes angle – how a weak risk assessment becomes a liability in enforcement and litigation.
- Tax treatment of tokens: the disputes angle – cross-border tax exposure that sits alongside the AML compliance stack.
FAQ
What does the Travel Rule require from a VASP?
The Travel Rule, derived from FATF Recommendation 15 and implemented in the EU through the Transfer of Funds Regulation and MiCA, requires a VASP or CASP to collect, verify and transmit originator and beneficiary information alongside a virtual-asset transfer above the applicable threshold. The obligation applies to both outbound and inbound transfers. Where the counterparty VASP does not send compliant data, the receiving firm must have a documented procedure for handling the deficiency – BaFin expects that procedure to be embedded in the monitoring program, not handled on an ad hoc basis.
Who must act as MLRO for a crypto firm?
Under the GwG, the Money Laundering Reporting Officer must be a natural person with sufficient seniority to escalate findings directly to management and, where required, to BaFin or the German FIU. The role can in certain structural conditions be outsourced to an external provider, but BaFin scrutinizes such arrangements carefully, particularly for firms where the MLRO function is the primary compliance point of contact. The appointment, and any change in appointment, must be notified or filed with the regulator in the manner the applicable regime requires.
How do regulators audit crypto AML programs?
BaFin audits crypto AML programs through a combination of document requests, on-site inspections and supervisory interviews. The review typically examines the currency and quality of the business risk assessment, the calibration and testing logs for the monitoring system, the MLRO's access and escalation records, Travel Rule compliance evidence at the transaction level, and the completeness and timeliness of FIU filings. ESMA's convergence work under MiCA means that supervisory expectations are increasingly standardized across EU member states, raising the floor that any national-level program must meet.
OBOLUS is an independent digital-asset law boutique acting only for businesses. We advise exchanges, custodians, token issuers and funds on licensing across 70+ jurisdictions, on disputes and on-chain asset recovery across 25+ forums, and on the tax, banking and compliance that sit around them. Digital assets are the whole of our practice. We map the licence, monitoring and banking stack across operating, custody and payment layers before you commit – and we work alongside forensic partners to convert on-chain evidence into court-ready disclosure applications where enforcement becomes necessary. To discuss your situation, contact info@oboluslaw.com or message us at t.me/oboluslaw.
By Victor Olsen, Regulatory & Compliance Analyst – specialising in AML program design and BaFin supervisory engagement for digital-asset businesses across the EU.
This publication is general information about the law and does not constitute legal advice. It is not a substitute for advice tailored to your circumstances. OBOLUS accepts no liability for action taken or not taken on the basis of this material. For advice on your situation, contact info@oboluslaw.com.