Payment processing compliance is the set of industry standards, laws, and operational controls that businesses must follow to accept, transmit, and store payments securely and lawfully. Three frameworks form the foundation: PCI DSS (the card industry's security standard), PSD2 (the EU's payment services directive), and GDPR (the EU's data protection regulation). Together, they create what the EU compliance environment describes as a triple-compliance stack — every merchant, payment service provider, acquirer, and processor operating in Central Europe must navigate all three simultaneously.
Here is who this applies to and what the stakes are:
- Merchants accepting card payments must meet PCI DSS requirements and, if they store customer data, GDPR obligations.
- Payment service providers (PSPs) and payment institutions are directly regulated under PSD2, with licensing, SCA, and transparency obligations.
- Acquirers and processors carry PCI DSS validation duties and contractual responsibility for their downstream merchants.
- Non-compliance consequences range from card scheme fines and chargebacks to regulatory penalties under GDPR (up to 4% of global annual turnover) and PSD2 enforcement by national competent authorities.
Your immediate next step: identify whether you store, process, or transmit cardholder data (your Cardholder Data Environment, or CDE), then ask your PSP for their current Attestation of Compliance (AoC).
Table of Contents
- What payment processing compliance actually covers
- The three pillars: PCI DSS, PSD2, and GDPR compared
- How PSD2 applies in Central Europe
- What PCI DSS requires and how validation works
- GDPR and payment data: where privacy law meets payments
- How to scope, remediate, validate, and maintain compliance
- Technical controls that satisfy multiple frameworks at once
- Who is responsible for what across the payment chain
- Practical compliance checklist for currency-exchange operators
- Key Takeaways
- Why compliance programs fail before they start
- Currexchanger helps currency-exchange operators stay audit-ready
- Useful sources
- FAQ
What payment processing compliance actually covers
The term covers every control, rule, and obligation that applies the moment a payment touches your systems. That includes accepting card payments at a terminal or online, storing or transmitting Primary Account Numbers (PANs), initiating cross-border transfers, and handling refunds or currency conversions.
Which entities fall in scope:
- Merchants of all sizes — from a single-location currency exchange office to a multi-branch retail network — if they accept card payments or store payment data.
- Payment service providers — licensed institutions that initiate or execute payment transactions, including account information service providers (AISPs), payment initiation service providers (PISPs), and account-servicing payment service providers (ASPSPs).
- Acquirers — banks or institutions that process card transactions on behalf of merchants.
- Third-party processors and service providers — any vendor that stores, processes, or transmits cardholder data on your behalf, or that could affect the security of that data.
The scope question is not always obvious. A business using a fully hosted payment page (where the card data never touches its own servers) has a much smaller compliance footprint than one that stores PANs in a local database. Use this quick self-check:
- Do you store PAN, CVV, or full magnetic stripe data anywhere in your systems?
- Do you handle refunds, chargebacks, or currency conversions that involve cardholder data?
- Do you use third-party processors, and have you verified their current AoC?
- Do you collect or retain any personal data linked to a payment (name, address, payment identifiers)?
If you answered yes to any of these, you have active compliance obligations across at least one of the three frameworks.
The three pillars: PCI DSS, PSD2, and GDPR compared
Understanding the difference between these frameworks matters because they have different legal characters, different enforcement bodies, and different validation mechanisms.
PCI DSS is an industry standard, not a law. It is set by the PCI Security Standards Council and enforced contractually through card scheme rules (Visa, Mastercard). Compliance is validated annually through self-assessment questionnaires (SAQs) or onsite assessments by a Qualified Security Assessor (QSA), depending on transaction volume. Failure triggers fines from card schemes and, ultimately, loss of the ability to accept card payments.
PSD2 is EU law — Directive (EU) 2015/2366 — transposed into national law across all EU member states, including Central European countries such as Poland, Czech Republic, Hungary, Slovakia, and Austria. It is enforced by national competent authorities (NCAs) and overseen at the EU level by the European Banking Authority (EBA). PSD2 governs who can provide payment services, how they must authenticate users, and what they must disclose about fees and currency conversion.
GDPR — Regulation (EU) 2016/679 — is directly applicable EU law enforced by national data protection authorities (DPAs). Payment data almost always includes personal data, so GDPR applies whenever you process information that can identify a natural person in connection with a payment.
Where the three overlap: encryption requirements appear in all three. Breach notification is required under both GDPR (72-hour notification to the DPA) and PSD2 (major incident reporting to the NCA). Access controls and audit logging satisfy PCI DSS requirements while also supporting GDPR accountability obligations. The practical takeaway is that a well-designed compliance program addresses all three simultaneously rather than treating them as separate projects.
How PSD2 applies in Central Europe
PSD2 is the regulatory backbone for payment services across the EU, and Central European businesses are fully within its scope. The directive distinguishes sharply between entities that provide payment services and merchants that merely accept payments.
-
Who must be licensed under PSD2. Payment institutions, e-money institutions, AISPs, PISPs, and ASPSPs must hold authorization from their national competent authority. A currency exchange operator that only exchanges cash typically falls outside PSD2 scope, but one that initiates transfers or holds client funds may not. The EBA Q&A on spot FX trading clarifies that spot currency transactions structured as separate agreements — not reimbursements — often fall outside PSD2's payment services definition, which is a critical distinction for currency-exchange operators assessing their regulatory exposure.
-
Strong Customer Authentication (SCA). PSD2 mandates SCA for electronic payments, requiring at least two of three authentication factors: something the user knows (PIN/password), something the user has (device/token), and something the user is (biometric). Common implementations include one-time passwords via SMS or authenticator apps combined with a device check. Exemptions exist for low-value transactions and trusted beneficiaries, but PSPs must document their exemption logic.
-
Transparency and disclosure obligations. PSPs must disclose fees, execution times, and currency conversion terms before a transaction is executed. The EBA's Q&A on PSD2 transparency specifically addresses currency conversion mark-ups: PSPs must express the mark-up as a percentage over the European Central Bank (ECB) reference rate. Failing to disclose this clearly is treated as a transparency violation, not merely a minor oversight. For currency-exchange operators, this intersects directly with currency exchange reporting requirements that govern how mark-ups and rates must be communicated.
-
Incident reporting and operational resilience. PSD2 requires PSPs to maintain documented incident management procedures and report major security incidents to their NCA without undue delay. The EBA and ECB expect proportional security measures, meaning the controls must match the risk profile of the services offered. This is compliance as operational resilience: the incident management process must exist and be tested before an incident occurs, not assembled in response to one.
-
CESOP reporting. Payment service providers executing cross-border payments must record and report transaction data when they exceed 25 cross-border payments per quarter to a single payee in a single EU member state. This Central Register of Payment Information (CESOP) obligation is a VAT anti-fraud measure, but it creates a concrete data-collection and reporting workflow that PSPs operating across Central Europe must build into their systems.
What PCI DSS requires and how validation works
PCI DSS v4.0.1 applies to any entity that stores, processes, or transmits cardholder data. The first task is always scoping: defining the Cardholder Data Environment (CDE), which includes every system component that stores, processes, or transmits PAN, as well as systems that could affect the security of those components.
The 12 PCI DSS requirements
| Requirement | What it covers | Operational example |
|---|---|---|
| 1. Install and maintain network security controls | Firewalls and network segmentation | Segment the CDE from general office networks |
| 2. Apply secure configurations | Default passwords and unnecessary services | Harden all devices before deployment |
| 3. Protect stored account data | Encryption and data minimization | Never store CVV; encrypt stored PAN |
| 4. Protect cardholder data in transit | TLS encryption for data in motion | Enforce TLS 1.2+ on all payment endpoints |
| 5. Protect against malicious software | Anti-malware on all systems | Deploy and update endpoint protection |
| 6. Develop and maintain secure systems | Patch management and secure coding | Apply security patches within defined windows |
| 7. Restrict access to system components | Least-privilege access controls | Role-based access to CDE systems only |
| 8. Identify users and authenticate access | Unique IDs and MFA | Require MFA for all CDE administrator access |
| — | Physical security of cardholder data | Lock server rooms; log physical access |
| 10. Log and monitor all access | Audit trails and log management | Centralize logs; review daily |
| 11. Test security of systems and networks | Vulnerability scanning and penetration testing | Quarterly internal scans; annual pen test |
| 12. Support information security with policies | Documented security program | Maintain and review an information security policy |
Third-party responsibilities matter here. Using a payment processor or gateway does not remove your PCI DSS obligation. As Adyen's compliance documentation explains, merchants remain responsible for ensuring their service providers are PCI DSS compliant and must collect AoCs from each provider annually. Outsourcing reduces scope; it does not transfer accountability.
GDPR and payment data: where privacy law meets payments
Every payment transaction that can be linked to an identifiable person is personal data under GDPR. That covers names, email addresses, IBANs, card numbers (even truncated), IP addresses tied to a transaction, and device identifiers. For most businesses accepting payments, GDPR is not optional and not separate from payment compliance — it runs in parallel.
Key GDPR obligations for payment handlers:
- Lawful basis. Processing payment data requires a lawful basis — typically contract performance (processing a payment the customer initiated) or legal obligation (AML record-keeping). Consent is rarely the right basis for core payment processing.
- Data minimization. Collect only what you need. Storing full PAN when a token suffices is both a PCI DSS risk and a GDPR violation waiting to happen.
- Data Protection Impact Assessments (DPIAs). Required when processing is likely to result in high risk to individuals — for example, large-scale processing of financial data or systematic profiling of payment behavior.
- Breach notification. A personal data breach must be reported to the relevant national DPA within 72 hours of becoming aware of it. If the breach is likely to result in high risk to individuals, those individuals must also be notified without undue delay. For GDPR compliance in cross-border contexts, the 72-hour clock starts from the moment of awareness, not discovery of the full scope.
- Retention limits. Payment records must not be kept longer than necessary. Define and enforce retention periods — a common failure is retaining full transaction records (including PAN) years beyond any legal or business need.
Where PCI DSS and GDPR overlap, a single control can satisfy both. Encryption of stored cardholder data (PCI Requirement 3) also reduces GDPR breach impact. Access controls (PCI Requirement 7) support GDPR's accountability principle. The divergence comes in retention: PCI DSS may permit retention for dispute resolution purposes, while GDPR demands a proportionality assessment for the same data.
A common GDPR pitfall in payment processing: storing payment tokens linked to customer profiles without a clear legal basis or retention policy. Tokens are still personal data if they can be re-linked to an individual through the token vault.
How to scope, remediate, validate, and maintain compliance
Compliance is a lifecycle, not a project with an end date. Here is the sequence that works for most merchants and PSPs in Central Europe:
- Run a gap assessment. Compare your current controls against PCI DSS v4.0.1 requirements, PSD2 obligations, and GDPR requirements. A compliance risk assessment at this stage surfaces the gaps that carry the highest risk and cost to remediate.
Cost factors to plan for: QSA fees for a Level 1 assessment can be substantial, varying by scope complexity and geography. SAQ completion for smaller merchants is lower cost but still requires staff time and potentially external consultancy for gap remediation. Tooling for log management, vulnerability scanning, and automated monitoring adds recurring costs. Remediation labor — fixing network segmentation gaps, deploying MFA, rewriting data retention processes — is often the largest single cost driver and the hardest to estimate without a gap assessment.
Technical controls that satisfy multiple frameworks at once
The most efficient compliance programs build controls that satisfy PCI DSS, PSD2, and GDPR simultaneously. Here are the controls that do the most work:
- Centralized logging and monitoring: PCI Requirement 10 mandates audit trails. GDPR's accountability principle requires demonstrable records of processing. A transaction management system with immutable logs serves both purposes.
Pro Tip: Use your PSP's or gateway's validated PCI DSS compliance to reduce your own scope. Request their current AoC and confirm which controls they manage on your behalf. Document this in a shared-responsibility matrix — it is the fastest way to shrink your SAQ and your audit burden at the same time.
For businesses moving payment workloads to cloud infrastructure, a PCI DSS compliant cloud migration approach ensures that the shared-responsibility model with the cloud provider is documented and that inherited controls are verified before go-live.
Who is responsible for what across the payment chain
Responsibility in a payment chain is layered, and the contracts between parties determine who owns each control. The table below shows typical allocations — actual responsibilities depend on your specific agreements.
| Role | Encryption of card data | SCA implementation | Incident reporting to regulator | PCI DSS validation | GDPR breach notification |
|---|---|---|---|---|---|
| Merchant | Shared (if storing data) | Not required (accepts payments only) | Not required (unless also a PSP) | Required (own CDE) | Required (as data controller) |
| PSP / Payment institution | Yes (in transit and at rest) | Required (as PSP under PSD2) | Required (to NCA under PSD2) | Required (own systems) | Required (as data controller/processor) |
| Acquirer | Yes (card scheme data) | Not directly (merchant-facing) | Required (to card schemes) | Required (own systems) | Required (as data processor) |
| Third-party processor | Yes (within their environment) | Depends on service scope | Required (to card schemes/NCA) | Required (must provide AoC) | Required (as data processor) |
What to request from every vendor:
- Current PCI DSS AoC (dated within the last 12 months)
- Data processing agreement (DPA) under GDPR Article 28
- Penetration test summary or executive report (within the last 12 months)
- Incident notification SLA — how quickly will they tell you about a breach affecting your data?
Even when a processor handles encryption and validation, the merchant remains the data controller under GDPR and retains accountability for the processing. Outsourcing a control does not outsource the legal obligation. Financial compliance software integrations that connect your systems to AML/KYC and payment providers should include documented API-level controls and audit trails that you can produce in an inspection.
Practical compliance checklist for currency-exchange operators
Currency-exchange operators face a specific compliance profile that differs from standard merchants. Cash-based FX transactions, multi-currency accounts, and cross-border payment flows each carry distinct obligations.
Sector-specific scope considerations:
- Spot FX transactions structured as separate agreements (not reimbursements) may fall outside PSD2's payment services definition, per the EBA's Q&A on spot currency trading. Operators should document the structure of each service line and obtain legal confirmation of their PSD2 scope.
- CESOP reporting is triggered at 25 cross-border payments per quarter to a single payee in a single EU member state. Operators processing high volumes of cross-border transfers must build automated monitoring to detect when this threshold is approaching.
- AML/KYC obligations under the EU's Anti-Money Laundering Directives apply independently of PCI DSS and PSD2. Customer due diligence, transaction monitoring, and suspicious activity reporting are non-negotiable for any currency-exchange business.
- Multi-branch operators must ensure that compliance controls are consistent across all locations. A gap at one branch can expose the entire network.
How Currexchanger maps to compliance tasks:
| Compliance task | Currexchanger capability |
|---|---|
| Transaction logging and audit trails | Immutable transaction logs with timestamped records across all branches |
| AML/KYC verification | Integrated AML/KYC provider connections and document verification workflows |
| Role-based access control | Granular user permissions and multi-factor authentication |
| Reporting and CESOP monitoring | Automated report generation and configurable threshold alerts |
| AoC and vendor document tracking | Centralized document management for service provider attestations |
| Multi-branch oversight | Real-time dashboards and consolidated reporting across office networks |
Currexchanger's API integrations with external AML/KYC providers and banknote verification services mean that compliance data flows into a single system rather than being scattered across spreadsheets and email threads. For operators running automated regulatory compliance reporting, this consolidation is what makes continuous monitoring practical rather than theoretical.
Key Takeaways
Payment processing compliance in Central Europe requires simultaneous adherence to PCI DSS, PSD2, and GDPR — and the fastest path to compliance is scoping your CDE, collecting vendor AoCs, and building controls that satisfy all three frameworks at once.
| Point | Details |
|---|---|
| Three frameworks, one program | PCI DSS, PSD2, and GDPR overlap significantly — design controls that satisfy all three simultaneously. |
| Scope determines your burden | Reducing your CDE through tokenization or hosted payment pages cuts both PCI DSS validation effort and GDPR breach exposure. |
| Outsourcing shifts scope, not accountability | Merchants remain legally responsible for their service providers' compliance — collect AoCs annually. |
| CESOP triggers at 25 payments | PSPs executing more than 25 cross-border payments per quarter to a single payee in one EU member state must report to CESOP. |
| Currexchanger for operators | Currexchanger centralizes transaction logs, AML/KYC workflows, and multi-branch reporting to support continuous compliance for currency-exchange operators. |
Why compliance programs fail before they start
Most payment compliance failures are not technical. They are organizational. A business installs a firewall, completes an SAQ, and considers the job done — then a vendor relationship changes, a new branch opens, or a developer adds a payment field to a form, and the CDE expands without anyone noticing. The gap between the compliance snapshot and operational reality is where breaches and regulatory findings live.
The frameworks themselves are well-designed. PCI DSS v4.0.1 is more risk-based than its predecessors, giving organizations flexibility in how they meet requirements rather than mandating specific technologies. PSD2's SCA rules are demanding but implementable. GDPR's accountability principle is actually a useful forcing function — it requires you to document what you do, which means you have to understand it first.
What I find underestimated is the vendor management piece. Businesses spend significant effort on their own controls and almost none on verifying that their processors, gateways, and SaaS providers are actually compliant. An AoC from 18 months ago is not current compliance. A provider that was compliant when you signed the contract may not be compliant today. The shared-responsibility model only works if both sides are actively maintaining their half of it — and the merchant is the one who pays the fine when it breaks down.
The practical advice: build vendor AoC collection into a calendar workflow, not a one-time onboarding task. Set a reminder 60 days before each provider's annual validation expires. That single habit closes more compliance gaps than most technical projects.
Currexchanger helps currency-exchange operators stay audit-ready
Running a currency-exchange operation means compliance is never a background task. AML/KYC checks, transaction logs, multi-branch reporting, and CESOP threshold monitoring all need to happen in real time, not at the end of the quarter when an auditor asks for records.
Currexchanger is built specifically for this environment. The platform centralizes transaction management, automates AML/KYC document workflows, enforces role-based access with MFA across every branch, and generates the audit-ready reports that regulators and card schemes expect. Instead of assembling compliance evidence from five different systems, operators get a single dashboard that tracks what happened, who did it, and when. The result is less time preparing for audits and more time running the business.
Ready to see how it works for your operation? Explore the Currexchanger platform or work through the liquidity tracking guide to see how the reporting features apply to your specific currency flows.
Useful sources
The sources below are the primary references for payment processing compliance in Central Europe. Save them for audits, vendor checks, and internal training.
- EU PCI Compliance: Navigating GDPR and PSD2
- Visa — Payment card security and compliance resources
- PCI DSS v4.0.1 – Principal requirements and testing procedures (extract)
- Directive (EU) 2015/2366 (PSD2) — consolidated text
- EBA single rulebook Q&A on PSD2 transparency and currency conversion
- CESOP reporting guidelines — European Commission (guidelines v1.1)
- PCI DSS compliance guide | Adyen Docs
- 2023_6691 — Is Article 5 of Regulation 2021/1230 applicable on the spot currency trading?
FAQ
What does payment compliance mean?
Payment compliance means meeting all legal, regulatory, and industry requirements that apply to accepting, processing, and storing payments. In Central Europe, that means satisfying PCI DSS for card data security, PSD2 for payment service regulation, and GDPR for personal data protection.
Do I need to worry about PCI DSS compliance as a small merchant?
Yes. PCI DSS applies to any business that accepts card payments, regardless of size. Smaller merchants typically qualify for a Self-Assessment Questionnaire (SAQ) rather than a full QSA audit, and using a hosted payment page can reduce the SAQ to its shortest form (SAQ A).
What is the difference between PSD2 and PCI DSS?
PSD2 is EU law that regulates who can provide payment services and how they must authenticate users and disclose fees. PCI DSS is a card industry standard that sets security requirements for handling cardholder data. Both can apply to the same business, but they are enforced by different bodies and validated differently.
What happens if a business fails to comply with payment processing regulations?
Consequences vary by framework: PCI DSS non-compliance can result in card scheme fines and loss of card acceptance rights; GDPR violations can trigger fines up to 4% of global annual turnover; PSD2 breaches are enforced by national competent authorities and can include license suspension for regulated payment institutions.
How can Currexchanger help with payment processing compliance?
Currexchanger provides currency-exchange operators with centralized transaction logs, automated AML/KYC workflows, role-based access control with MFA, and configurable compliance reports — the operational infrastructure that supports PCI DSS audit trails, CESOP threshold monitoring, and GDPR accountability documentation in a single platform.