Crypto firms operating in Poland face a sanctions screening obligation that sits at the intersection of EU sanctions law, the Polish anti-money laundering (AML) regime, and the Financial Action Task Force (FATF) Travel Rule. Failure to screen counterparties in real time is not a technical oversight – it is an enforcement-grade compliance failure that can freeze payment rails, suspend banking relationships and attract regulatory scrutiny from the General Inspector of Financial Information (GIIF), Poland's primary AML supervisory authority. This page maps the legal basis, the operational requirements and the cross-border interaction that any crypto business touching Polish users or Polish infrastructure must understand.
The regulated basis for sanctions screening in Poland
Every virtual asset service provider (VASP) – a firm accepting, transmitting, exchanging or custodying digital assets on behalf of customers – that operates in Poland is an obligated institution under the Polish AML Act, which transposes the EU's AML Directives into national law. The sanctions obligation runs separately and in parallel: under EU sanctions regulations, which are directly applicable across all member states, and under Poland's domestic implementation framework. A VASP does not choose between these two bodies of law; it complies with both simultaneously.
The GIIF supervises crypto firms for AML/CFT compliance, including sanctions screening. At the EU level, ESMA and the European Banking Authority have issued guidance on the application of sanctions rules to crypto-asset service providers under MiCA (the Markets in Crypto-Assets Regulation). With MiCA now in its full application phase across the EU, CASP (crypto-asset service provider) authorisation in any member state triggers the EU sanctions framework directly, and Poland is no exception.
Practically, this means a firm with a Polish regulatory footprint – whether registered with the GIIF under the domestic VASP rules or operating via an EU passport into Poland – must screen every customer, counterpart and wallet address against the EU Consolidated Sanctions List, the OFAC Specially Designated Nationals list where USD or US-nexus exposure exists, and any other applicable list given the firm's user base and banking relationships. The duty is continuous, not periodic.
Who needs to screen, and when does the obligation arise?
The obligation to screen arises at onboarding and on a rolling basis for existing customers whenever a sanctions list is updated. Under the applicable EU provisions, a VASP that processes transactions – including on-chain transfers – for a sanctioned person commits a violation even if the underlying transfer was initiated before designation. The real-time nature of that duty is what makes blockchain-native screening architecturally different from traditional financial services screening.
In our practice, the firms that encounter problems are rarely those that skip screening altogether. They are firms that screen at onboarding but do not re-screen when a counterparty is designated mid-relationship, or that screen customer names but not wallet addresses against blockchain analytics outputs. Both gaps are exploitable in an enforcement context, and the GIIF has broad authority to request compliance documentation during its supervisory reviews.
The obligation applies to:
- Exchanges and brokers accepting Polish-resident users.
- Custodians holding assets on behalf of Polish-domiciled entities.
- Payment processors routing crypto payments through Polish accounts or Polish legal entities.
- Token issuers conducting a public offer in Poland, where the issuer has contact with identifiable investors.
Operating without the right compliance architecture risks enforcement, frozen payment rails and the loss of Polish banking relationships – a outcome that typically costs far more to remediate than the original build.
CTA #1: The compliance architecture described above is the standard path. Your specific entity structure, user geography and banking stack will shape the analysis materially. Map your options with the OBOLUS compliance desk before your next onboarding sprint.
What does an effective screening architecture look like?
Effective sanctions screening for a Polish-regulated crypto firm rests on four operational layers that must work together: list screening, blockchain analytics, transaction monitoring and an escalation workflow.
List screening covers the EU Consolidated Sanctions List (published and updated by the EU on its official sanctions map), OFAC lists, and any additional national lists published by the Polish government. The screening must be automated and must cover legal entity names, natural persons, registered addresses and, critically, any wallet addresses associated with designated parties. Major forensics platforms – including Chainalysis, TRM Labs and Elliptic, which the firm may engage independently – maintain updated wallet-address intelligence that can be integrated into a compliance stack.
Blockchain analytics is the layer that distinguishes crypto compliance from TradFi screening. A firm that screens names but not on-chain provenance will pass an EU-sanctioned entity whose wallet address has been identified by forensics tools. The GIIF and, at the EU level, national competent authorities under MiCA increasingly expect that obligated CASPs can demonstrate a risk-based blockchain analytics capability. "Risk-based" means calibrated to the firm's transaction volumes, asset types and user risk profile – not a single off-the-shelf feed applied uniformly to every wallet.
Transaction monitoring complements sanctions screening but is distinct from it. Monitoring identifies unusual patterns – structuring, layering, rapid cross-exchange movement – whereas sanctions screening identifies prohibited counterparties. Both are required; neither substitutes for the other. Under the Polish AML Act, suspicious transaction reports (STRs) must be filed with the GIIF when monitoring generates a credible suspicion. The timeline for filing is defined by statute, and a firm that cannot demonstrate a documented escalation workflow will struggle in a supervisory review.
The escalation workflow closes the loop. When a screen generates a positive match or a potential match, the firm needs a documented process: who reviews, what information is gathered, who decides to block or exit, and how the decision is recorded. That record is what regulators inspect. In practice, many firms build technically capable screening tools but neglect the governance layer – the written policies, the designated reviewer roles and the audit trail.
Who is the MLRO, and what do they own?
Under the Polish AML Act, a registered VASP must designate a Money Laundering Reporting Officer (MLRO) – a named individual who bears personal responsibility for the AML and sanctions compliance function, including the filing of STRs with the GIIF. The MLRO is not a nominal title. Polish law holds the MLRO accountable for the adequacy of the program, and the GIIF may examine the MLRO directly during a supervisory visit.
The MLRO must be sufficiently senior to have genuine authority over compliance decisions – including the authority to refuse or exit a customer relationship. In smaller firms, this is frequently the CCO or a co-founder. In regulated entities operating at scale, the MLRO role should be separated from commercial and product functions to avoid conflicts.
Where a non-resident entity operates in Poland through a branch or an agent, or where a foreign-incorporated VASP accesses Polish users, the question of where the MLRO sits becomes a cross-border question. Regulators expect the MLRO to have a credible relationship with the Polish supervisory environment – in practice, this often means a Polish-resident senior compliance officer, even if the firm is legally domiciled elsewhere in the EU and passporting under MiCA.
How does the Travel Rule operate for Polish VASPs?
The Travel Rule – the obligation, derived from FATF Recommendation 15 and implemented across the EU via the Transfer of Funds Regulation – requires a VASP to pass originator and beneficiary information with every qualifying crypto transfer. In the EU context, this obligation applies to CASPs under the Transfer of Funds Regulation, which came into full effect alongside MiCA's broader application timeline.
For a Polish-registered VASP or a CASP passporting into Poland, the Travel Rule imposes a specific technical requirement: the firm must be capable of collecting the relevant originator data (name, account number or wallet identifier, address and, in some cases, identification document reference), transmitting it securely to the beneficiary VASP, and receiving equivalent data on inbound transfers. Where the beneficiary VASP is in a jurisdiction outside the EU that has implemented the Travel Rule, reciprocal exchange is expected. Where the counterpart is in a non-implementing jurisdiction, the firm must apply enhanced due diligence and, in some cases, may need to decline the transfer.
Travel Rule compliance intersects with sanctions screening because the originator/beneficiary data obtained through Travel Rule messaging is itself screening data. A firm that receives Travel Rule data identifying a counterparty as a designated person must act on that information – it cannot process the transfer and treat the Travel Rule and sanctions obligations as parallel but independent systems.
The threshold question – below what transfer value does the Travel Rule not apply – is set by the EU Transfer of Funds Regulation, and the applicable threshold is stated in the regulation itself. Operators should consult current legislation for the operative figure, as thresholds are subject to amendment.
Cross-border interaction: banking, tax and inbound operators
A Polish crypto business's compliance program does not operate in a vacuum. It sits at the intersection of three cross-border realities that shape both the operational build and the enforcement risk.
First, banking. Polish banks applying correspondent-banking due diligence to crypto clients expect documented evidence of a functioning sanctions screening program. A firm that cannot produce its screening policy, its list sources, its false-positive management procedure and its MLRO appointment letter will struggle to maintain a Euro account in Poland. The banking relationship is, in practice, a compliance lever: banks exercise de-risking rights swiftly when a crypto client's AML documentation is inadequate, regardless of the client's formal regulatory status.
Second, tax. Poland applies income tax to crypto disposals, and the chain-of-custody documentation generated by a compliant AML program – transaction records, KYC files, wallet-address mappings – is also the evidential base for accurate tax reporting. A firm that builds a strong compliance stack indirectly builds its tax-reporting infrastructure. Conversely, a firm that maintains minimal AML records will face difficulty reconstructing cost-basis and disposal data at the end of a fiscal year.
Third, inbound operators. A firm incorporated outside Poland – in, say, a UAE free zone or a Cayman entity – that targets Polish users is, in most circumstances, subject to the Polish AML Act for activities conducted in relation to Polish residents. The regulatory perimeter follows the customer, not the incorporation address. This is a point that firms with offshore structures frequently underestimate. Operating via an intermediary or a payments partner does not transfer the sanctions obligation; the originating entity remains exposed if it has the capacity to identify and exclude sanctioned parties but fails to do so.
We regularly advise inbound operators on how to structure the compliance function so that the obligations of the local Polish operations are met without requiring every compliance decision to route through a head-office legal team in a different time zone – a design that creates both operational delays and documentary gaps.
CTA #2: If a prior compliance build stalled – or if a banking relationship was closed following a GIIF inquiry – a structural review can surface the design gap and chart a route back. Map your options with OBOLUS before the next supervisory cycle.
An anonymized illustration
In a recent compliance engagement, a payments company had registered as a VASP in Poland and built a name-screening program against the EU Consolidated Sanctions List. The firm's transaction volumes grew, and the product team integrated a non-custodial wallet feature that allowed users to receive transfers from external addresses. During an internal review in the fourth quarter, we identified that the firm's screening tool was not ingesting blockchain analytics data for those inbound wallet addresses – a gap that meant a proportion of transfers from wallets associated with sanctioned entities were passing undetected. We restructured the analytics integration, updated the firm's screening policy to cover on-chain provenance alongside legal-entity screening, and documented the escalation workflow to MLRO level. The GIIF's subsequent supervisory request was responded to with a complete and auditable compliance file.
Decision matrix: which firms need what level of program?
Not every Polish crypto firm needs the same compliance architecture. The risk-based approach mandated by the Polish AML Act and by FATF Recommendation 15 requires a program proportionate to the firm's risk profile. The key variables are transaction volume, customer type, asset class and counterpart geography.
A retail-facing exchange with high transaction volumes and a broad user base requires a fully automated screening stack – real-time list screening, blockchain analytics for every incoming transfer, automated STR-generation tooling and a dedicated MLRO with support staff. Manual processes are not viable at scale, and regulators will assess whether the program is architecturally capable of meeting the obligation, not merely whether a policy document exists.
An institutional OTC desk with a small number of vetted counterparties and lower transaction frequency can operate a more manual program at lower cost, but must still demonstrate on-chain provenance screening for each counterparty wallet and a documented re-screening procedure when sanctions lists are updated. The MLRO function here is often held by a senior partner or compliance officer who can spend focused time on each transaction.
A token issuer conducting a public offer in Poland must screen investors at the time of subscription and must maintain the capacity to freeze a token allocation if a subscriber is subsequently designated. The mechanics of that freeze depend on whether the token is held in a custodial structure the issuer controls or in non-custodial wallets – a technical design question with significant compliance consequences.
In each profile, the common failure mode is the same: a program that is adequate on paper but not operationally implemented. The gap between a written sanctions policy and a functioning screening workflow is where enforcement actions originate.
How does the GIIF supervise and audit compliance programs?
The GIIF exercises its supervisory powers through documentary requests, on-site inspections and, where it identifies systemic failures, formal enforcement proceedings. A supervisory visit will typically examine: the AML/CFT policy and its last review date; the MLRO appointment and their access to senior management; the screening tool configuration and its list sources; a sample of STR filings and their supporting documentation; and the firm's training records for compliance-relevant staff.
Regulators in the leading European hubs increasingly expect that obligated CASPs can demonstrate a live, auditable compliance program – not a policy document filed at registration and not revisited. The Polish supervisory environment has aligned with that expectation as MiCA has taken effect, and VASP firms that transition to CASP authorisation under MiCA will face a more structured supervisory engagement than existed under the pre-MiCA registration regime.
A practical implication for firms planning their compliance calendar: the internal audit of the screening program should be completed before any anticipated supervisory contact, not after. A firm that identifies and remediates a gap voluntarily is in a materially different position from one that has the gap identified by a regulator. The GIIF's enforcement discretion – and its approach to proportionate remediation – reflects that distinction.
We have seen firms accelerate their compliance build substantially in the weeks before a scheduled GIIF supervisory visit, and in some cases that compressed timeline has resulted in documentation gaps that a more systematic build would have avoided. The better posture is to treat each compliance review cycle as a standing commitment, not an acute-response exercise.
Related at OBOLUS
- AML, Travel Rule and compliance for digital-asset businesses – our core compliance practice across 70+ jurisdictions and regulatory regimes.
- Transaction monitoring setup in the Czech Republic – parallel obligations and practical build considerations for a neighboring EU market.
- Smart contract dispute resolution for institutional clients – recovery and enforcement where on-chain transactions are in dispute.
FAQ
What does the Travel Rule require from a VASP?
The Travel Rule – derived from FATF Recommendation 15 and implemented in the EU via the Transfer of Funds Regulation – requires a VASP to collect, verify and transmit originator and beneficiary information alongside every qualifying crypto transfer. This includes the sender's name, account or wallet identifier, and, depending on the transfer value and the applicable jurisdiction's rules, additional identification data. The obligation applies both to outbound transfers and to inbound transfers received from counterpart VASPs.
Who must act as MLRO for a crypto firm?
Under the Polish AML Act, a VASP or CASP must designate a named Money Laundering Reporting Officer who bears personal accountability for the firm's AML and sanctions compliance, including the submission of suspicious transaction reports to the GIIF. The MLRO must be senior enough to have genuine authority over compliance decisions. For non-resident entities with Polish-facing operations, regulators generally expect the MLRO to have a credible connection to the Polish supervisory environment.
How do regulators audit crypto AML programs?
The GIIF audits crypto AML programs through documentary requests and on-site inspections examining: AML policy documentation and its review history; MLRO appointment records; screening tool configuration and list sources; samples of suspicious transaction report filings; and staff training records. Under MiCA's CASP authorisation regime, supervisory engagement has become more structured. Firms should treat their compliance program as a continuously auditable system, not a filing completed at registration.
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 frameworks that sit around them. Digital assets are the entirety of our practice. We map the licence, compliance and banking stack across operating, custody and payment layers before a client commits – and we act only for businesses, not retail investors. To discuss your situation, contact info@oboluslaw.com.
By Victor Olsen, Regulatory & Compliance Analyst – specialising in AML regime obligations, sanctions screening architecture and VASP compliance across EU and cross-border mandates.
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.