When we started building Proxy.forex, we knew from day one that PCI DSS Level 1 compliance was not optional -- it was foundational. As a payment gateway processing card transactions for forex brokers, we handle cardholder data at scale, and the security of that data is the bedrock of our entire business. There is no "we will add security later" in payments. You either build it right from the start, or you build technical debt that becomes exponentially more expensive to fix.

This post is a detailed, technical walkthrough of how we designed, built, and maintain a PCI DSS Level 1 compliant payment system. I am writing this because when we started this journey, we found very few practical resources from people who had actually done it. Most PCI content is either vendor marketing or compliance consultant jargon. This is the guide I wish we had three years ago.

Why PCI DSS Level 1 Matters for Forex Payment Gateways

PCI DSS (Payment Card Industry Data Security Standard) has four compliance levels, determined by annual transaction volume. Level 1 applies to any entity processing more than six million card transactions per year. Proxy.forex crossed that threshold in early 2024, but we had been building to Level 1 standards from the beginning because retroactively upgrading a payment system's security architecture is orders of magnitude harder than doing it right initially.

For forex payment gateways specifically, Level 1 compliance carries additional weight. The forex industry is classified as high-risk by card networks, which means acquiring banks and payment processors scrutinize our security posture more aggressively than they would a standard e-commerce merchant. A PCI DSS Level 1 certification -- validated by an annual on-site assessment from a Qualified Security Assessor (QSA) -- is often a prerequisite for establishing and maintaining acquiring relationships in the high-risk space.

Beyond the commercial necessity, PCI DSS Level 1 compliance represents a genuine security standard that protects both our clients and their traders. A data breach in the payment processing chain does not just result in fines and reputational damage -- it destroys the trust that every broker depends on with their traders. When a trader enters their card details to fund a trading account, they are trusting the entire chain to protect that data. We take that trust seriously.

The 12 PCI DSS Requirements: A Practical Overview

PCI DSS v4.0 organizes its requirements into six goals and twelve requirement families. Rather than listing them academically, let me frame them in terms of the practical engineering decisions they drove for us. Requirements 1 and 2 cover network security -- firewalls, segmentation, and secure configurations. Requirements 3 and 4 address data protection -- encryption at rest and in transit. Requirements 5 and 6 deal with vulnerability management -- patching, anti-malware, and secure development. Requirements 7, 8, and 9 handle access control -- authentication, authorization, and physical security. Requirements 10 and 11 cover monitoring -- logging, intrusion detection, and testing. Requirement 12 addresses organizational policy -- the human and process side of security.

The mistake most engineering teams make is treating PCI DSS as a checklist to be satisfied after the system is built. In reality, these twelve requirements should inform your architecture from the first design document. Every requirement maps to specific architectural decisions, and those decisions are dramatically cheaper to make early than to retrofit later. Let me walk through the key areas where we made those decisions.

Network Segmentation Architecture

Network segmentation is arguably the most impactful architectural decision in PCI compliance because it determines the scope of your Cardholder Data Environment (CDE). Everything inside the CDE is subject to the full weight of PCI DSS requirements. Everything outside it is not. The smaller your CDE, the smaller your compliance surface area, and the easier (and cheaper) it is to maintain compliance.

We designed our network into three distinct zones. The DMZ (Demilitarized Zone) faces the public internet and hosts our API gateways, load balancers, and web application firewalls. No cardholder data is stored or processed in the DMZ -- it is purely a traffic routing and filtering layer. The CDE is a completely isolated network segment that houses our payment processing services, tokenization engine, and encrypted card data storage. The internal network hosts everything else: our broker dashboard, analytics services, monitoring infrastructure, and internal tooling.

Traffic between zones is controlled by stateful firewalls with explicit allow-list rules. The CDE accepts inbound connections only from specific DMZ services on specific ports, and all inter-zone traffic is encrypted with mutual TLS. We implemented microsegmentation within the CDE itself, so even if an attacker compromised one service inside the CDE, lateral movement to other services would require bypassing additional network-level controls. Every firewall rule is documented, reviewed quarterly, and any change requires approval from both engineering and security leadership.

Encryption Strategy: At Rest, In Transit, and Tokenization

Encryption is where PCI DSS requirements 3 and 4 live, and getting it right requires thinking about data protection across three dimensions: at rest (stored data), in transit (data moving between systems), and in use (data being actively processed).

For data at rest, we use AES-256 encryption for all cardholder data stored in our databases. But encryption alone is not sufficient -- the critical question is key management. If your encryption keys are stored alongside the encrypted data, you have not actually protected anything. Our encryption keys are managed by Hardware Security Modules (HSMs) that provide tamper-resistant key storage and perform cryptographic operations without ever exposing the raw key material to the application layer. I will cover our HSM architecture in more detail in a later section.

For data in transit, we enforce TLS 1.3 on all connections, both external (client-to-server) and internal (service-to-service within the CDE). We disabled TLS 1.0 and 1.1 entirely, and TLS 1.2 is only permitted on a handful of legacy acquirer connections where the acquirer does not yet support 1.3. Every internal service communicates via mutual TLS (mTLS), where both the client and server present certificates, preventing unauthorized services from connecting to CDE components even if they gain network access.

Tokenization is our primary strategy for minimizing the scope of cardholder data exposure. When a card number enters our system, it is immediately tokenized -- replaced with a non-reversible token that can be used for subsequent operations without exposing the actual PAN (Primary Account Number). The tokenization service runs inside the CDE and is the only component that can map tokens back to real card numbers. This means that the vast majority of our application code, including the broker-facing dashboard and analytics services, never touches real cardholder data. They work exclusively with tokens.

Access Control and Authentication

PCI DSS requirements 7, 8, and 9 mandate strict access controls based on the principle of least privilege: no person or system should have more access than they need to perform their function. For a growing engineering team, implementing this without creating a bureaucratic bottleneck requires careful system design.

We implement Role-Based Access Control (RBAC) across all systems. Every engineer has a base role that grants access to development environments, CI/CD pipelines, and non-production systems. Access to production systems requires an elevated role, and access to CDE systems requires an additional security clearance that includes a background check and PCI-specific security training. Currently, only 12 out of 85 employees have any access to the CDE, and even within that group, access is scoped to specific services.

Multi-factor authentication (MFA) is mandatory for all system access, without exception. We use hardware security keys (YubiKeys) as the primary MFA factor for CDE access, and TOTP-based authenticators are accepted for non-CDE systems. Password policies enforce minimum complexity requirements and 90-day rotation cycles. All access is logged and reviewed monthly, and any access that has not been used in 30 days is automatically revoked, requiring re-approval to restore.

For service-to-service authentication within the CDE, we use short-lived certificates issued by our internal certificate authority with a maximum lifetime of 24 hours. Services must re-authenticate daily, and certificate issuance is fully automated through our infrastructure-as-code pipeline. This eliminates the risk of long-lived credentials being compromised and used for persistent access.

Logging and Monitoring Infrastructure

PCI DSS requirement 10 mandates comprehensive logging of all access to cardholder data and all actions taken by anyone with administrative privileges. Requirement 11 requires regular testing, including intrusion detection. Our approach goes well beyond the minimum requirements because in payments, the difference between detecting a breach in minutes versus hours can mean millions of dollars in exposure.

Our logging infrastructure is built on a centralized SIEM (Security Information and Event Management) platform that ingests logs from every component in our stack: application logs, database audit logs, firewall logs, OS-level system logs, and network flow data. Every log entry includes a UTC timestamp, the source system, the user or service identity, and a structured description of the action taken. Logs are immutable once written -- they are shipped in real time to a separate, append-only storage system that even system administrators cannot modify or delete.

On top of the raw logging layer, we run an anomaly detection system that uses statistical models to identify unusual patterns. This includes things like a service account making requests at unusual hours, an abnormal spike in database queries against cardholder data tables, or a user accessing records outside their normal scope. When an anomaly is detected, it triggers an alert that is triaged by our security team within a 15-minute SLA during business hours and a 30-minute SLA outside of them.

Audit trails are retained for a minimum of twelve months in immediately accessible storage and an additional twelve months in archived storage, exceeding the PCI DSS minimum of one year. We have found that retaining 24 months of audit data is invaluable for investigating patterns that only become apparent over longer time horizons, particularly for detecting slow, sophisticated attack campaigns.

Vulnerability Management Program

PCI DSS requirements 5 and 6 address vulnerability management and secure systems development. For a payment gateway that is continuously deploying new features, this requires embedding security into the development lifecycle rather than treating it as a gate at the end.

We conduct quarterly external vulnerability scans through an Approved Scanning Vendor (ASV), as required by PCI DSS. But quarterly scans are the bare minimum. Internally, we run automated vulnerability scans weekly across all CDE systems, and our CI/CD pipeline runs container image scanning on every build. Any vulnerability rated Critical or High must be patched within 48 hours for CDE systems and within 7 days for non-CDE production systems. We track patching SLA compliance as a key engineering metric, and our current 30-day average is 96% on-time.

Annual penetration testing is conducted by an independent third-party firm that specializes in financial services and payment systems. We engage them for both network-level and application-level testing, including attempts to breach the CDE from both external and internal vantage points. The results are shared with our QSA and feed directly into our remediation backlog. In 2025, our penetration test identified three medium-severity findings, all of which were remediated within two weeks and verified by the testing firm.

Secure SDLC: Building Security Into Development

Our Secure Software Development Lifecycle (SSDLC) is designed to catch vulnerabilities before they reach production. It starts with threat modeling during the design phase of any new feature that touches the CDE. Before writing a single line of code, the engineering team and a security engineer map out the potential attack vectors, trust boundaries, and data flows of the proposed feature. This catches entire categories of issues -- like unnecessary cardholder data exposure or overly permissive API endpoints -- before any implementation begins.

Every pull request goes through mandatory code review by at least two engineers, one of whom must be a designated security reviewer for CDE changes. Our CI pipeline runs Static Application Security Testing (SAST) using Semgrep and SonarQube, which scan for common vulnerability patterns including SQL injection, cross-site scripting, insecure cryptographic usage, and hardcoded secrets. Dynamic Application Security Testing (DAST) runs nightly against our staging environment, simulating real attacks against our API surface.

Dependency scanning is another critical layer. We use Snyk to continuously monitor our dependency tree for known vulnerabilities. When a new CVE is published that affects one of our dependencies, Snyk creates an automated pull request with the patched version. For CDE services, dependency updates that address security vulnerabilities are treated as priority-one incidents and are deployed within 24 hours of a patch being available.

We also maintain a library of security-focused integration tests that specifically target the OWASP Top 10 vulnerability categories. These tests run on every deployment and serve as a regression suite that prevents previously fixed vulnerabilities from being reintroduced. The test suite currently contains over 400 security-specific test cases and grows with every vulnerability finding.

Key Management and HSM Architecture

Encryption is only as strong as the key management behind it, and PCI DSS requirement 3 has extensive sub-requirements around cryptographic key lifecycle management. This is the area where we see the most startups cut corners, often storing encryption keys in environment variables or configuration files alongside the encrypted data. That approach provides no meaningful security -- it is the equivalent of locking a door and leaving the key under the doormat.

Our key management architecture is built around FIPS 140-2 Level 3 certified Hardware Security Modules (HSMs). These are dedicated cryptographic processors that generate, store, and perform operations with encryption keys without ever exposing the raw key material outside the HSM boundary. When our tokenization service needs to encrypt a card number, it sends the plaintext to the HSM, which performs the encryption internally and returns the ciphertext. The encryption key never exists in application memory.

We implement a hierarchical key structure with three levels. The Key Encryption Key (KEK) is the master key stored exclusively in the HSM and is used only to encrypt other keys. Data Encryption Keys (DEKs) are generated by the HSM and used for bulk data encryption -- these are the keys that actually encrypt cardholder data. Session keys are ephemeral keys generated for individual transactions and destroyed after use. This hierarchy means that compromising a single DEK exposes only the data encrypted with that specific key, not the entire dataset.

Key rotation is automated on a quarterly cycle for DEKs, with the KEK rotated annually during a controlled ceremony that requires the presence of at least three key custodians. The rotation process re-encrypts all active data with the new key and securely destroys the old key material after a verification period. We maintain detailed records of every key lifecycle event, from generation through rotation to destruction, as required by our QSA.

The QSA Audit Process: What to Expect

The PCI DSS Level 1 assessment is conducted by a Qualified Security Assessor (QSA) -- an independent auditor certified by the PCI Security Standards Council. The assessment is thorough, time-consuming, and often stressful, but understanding what to expect makes the process significantly smoother.

Our annual assessment typically spans 8-10 weeks. It begins with a scoping exercise where the QSA maps our systems, data flows, and network architecture to determine which components are in scope for the assessment. This is where proper network segmentation pays dividends -- a well-segmented architecture dramatically reduces the number of systems the QSA needs to evaluate. The QSA then reviews documentation, interviews key personnel, examines system configurations, reviews logs and monitoring data, and conducts their own vulnerability scanning.

Common findings that trip up payment companies include incomplete or outdated network diagrams, inconsistent firewall rules that do not match documentation, gaps in log coverage (particularly for database access), weak password policies on legacy systems, and missing evidence of periodic security reviews. We maintain a "PCI evidence library" -- a continuously updated repository of documentation, screenshots, configuration exports, and test results that maps directly to each PCI DSS requirement. This library is our single source of truth during the assessment and eliminates the frantic evidence-gathering scramble that many companies experience.

Our most recent assessment in 2025 resulted in zero findings -- no non-compliance issues identified. This was the result of three years of building compliance into our engineering culture rather than treating it as an annual checkbox exercise. The QSA specifically noted our logging infrastructure and key management architecture as best-in-class examples.

Maintaining Compliance Continuously

Achieving PCI DSS Level 1 certification is hard. Maintaining it is harder. The standard is not a point-in-time snapshot -- it requires continuous compliance, and your QSA can (and will) verify that controls have been operating effectively throughout the entire assessment period, not just on the day they visit.

We built an internal compliance dashboard that tracks over 150 PCI DSS control points in real time. Each control point has an owner, a verification method (automated or manual), a review frequency, and a current compliance status. Automated controls are verified continuously through our monitoring infrastructure -- for example, a control that requires TLS 1.2 or higher on all connections is verified by our network monitoring system, which alerts immediately if a TLS 1.0 or 1.1 connection is detected anywhere in the CDE.

Manual controls are tracked through a recurring task system with escalation paths. For example, the quarterly review of firewall rules is assigned to the network security team, with automatic reminders at 30, 15, and 7 days before the due date. If a review is not completed on time, it escalates to the VP of Engineering and then to me. We treat missed compliance deadlines with the same urgency as production incidents because, in a regulated industry, a compliance failure is a production failure.

Every new employee who will have any access to CDE systems completes a PCI DSS security awareness training program before their access is provisioned. This training is refreshed annually for all personnel in scope. Beyond the formal training, we run quarterly tabletop exercises that simulate security incidents -- data breach scenarios, insider threat situations, and ransomware attacks -- to ensure our incident response procedures are well-understood and regularly practiced.

Lessons Learned and Advice for Startups

If I could give one piece of advice to any startup building a payment system, it would be this: design for PCI DSS from day one, even if you are years away from Level 1 volumes. The architectural decisions that enable compliance -- network segmentation, encryption, tokenization, centralized logging, least-privilege access -- are also just good engineering practices. They are dramatically cheaper to implement at the beginning than to retrofit later.

Second, invest in automation early. Manual compliance processes do not scale. When you have 10 servers and 5 engineers, you can manually review firewall rules and access logs. When you have 200 services and 85 engineers, you cannot. Our compliance automation infrastructure -- the dashboards, the automated scanning, the evidence library -- took significant upfront investment, but it now saves us hundreds of engineering hours per quarter and gives us confidence that we are compliant at every moment, not just during audit season.

Third, choose your QSA carefully. Not all QSAs are created equal. The best ones are technically rigorous but also collaborative -- they help you understand the intent behind requirements and find practical implementations, rather than just checking boxes. A good QSA relationship is a partnership, not an adversarial audit. We spent three months evaluating QSA firms before selecting ours, and that investment has paid dividends in the quality of our assessments.

Finally, make security a cultural value, not just a technical requirement. The most sophisticated security architecture in the world is irrelevant if an engineer hardcodes a database password in a configuration file or a support agent shares credentials over Slack. Security culture is built through education, tooling that makes the secure path the easy path, and leadership that treats security incidents with appropriate gravity. At Proxy.forex, every engineer understands that they are personally responsible for the security of the systems they build, and that responsibility is something we take pride in.