Written by Jonathan Mizzi, Chief Information Officer of Finance Incorporated Limited
When building a fintech product, slick interfaces and rapid releases don’t mean much if you can’t prove security on demand. In payments, that discipline starts with Payment Card Industry-Data Security Standard (PCI-DSS) and runs through everything, how you design your architecture, manage vendors, train teams, and run day‑to‑day operations. For an Electronic Money Institution (EMI), PCI isn’t a footer logo; it’s the muscle behind every transaction, every deployment, every support interaction. With PCI-DSS v4 now being the norm, the mindset has shifted from a once‑a‑year, point‑in‑time audit to continuous, risk‑based assurance. In practice, you don’t just say you’re secure – you show it, every day, with evidence that your controls work. You don’t prove security once a year; you live it and you keep the receipts.
PCI-DSS and EMIs
PCI-DSS is the global baseline for how we store, process, and transmit cardholder data. For an EMI, it’s also a pragmatic blueprint for preventing fraud and reputational damage, earning scheme and partner approvals, and reducing the cost and chaos of incidents.
Crucially, PCI compliance embraces a risk‑based approach. It does not demand that you clone someone else’s control set; it expects you to design the right controls for your architecture and prove they operate effectively. If your systems touch a PAN (Primary Account Number) in any form – including logs, error traces, and screenshots, you’re in scope, and the burden of care is yours.
PCI-DSS at the Workplace
When I explain PCI internally, I anchor it in four habits we practice every day. First, we build a digital fort around the payment environment. The cardholder data environment is segmented and isolated, with hardened systems and tight ingress and egress rules.
Second, we enforce need‑to‑know access. People see only what they must to perform their jobs, roles are narrowly defined, sessions are short, and multi‑factor authentication is a default rather than a debate.
Third, we encrypt everywhere and treat keys like crown jewels, with disciplined rotation and tight custody. If an attacker ever slips inside, the data is worthless if they do not have the right keys.
Fourth, we practice constant vigilance. Logs flow to a central platform, alerts are tuned for signal over noise, vulnerabilities are scanned and remediated on cadence, and penetration and segmentation tests are scheduled, recurring, and non‑negotiable.
Operating in Malta-Europe means PCI lives inside a broader regulatory frame. The Malta Financial Services Authority (MFSA) requires robust governance, clear risk ownership, and rigorous supplier oversight-especially for cloud and payment processors. The General Data Protection Regulation (GDPR) reminds us that cardholder data is personal data; hence, beyond security we owe customers minimisation, controlled retention, lawful basis, and the operational ability to honour rights requests. The Digital Operational Resilience Act (DORA) raises the bar on digital resilience, pushing formal ICT risk management, incident reporting, resilience testing, and third‑party risk.
The practical lesson is that PCI is necessary but not sufficient. The winning approach is a single, coherent control set that serves PCI while mapping to MFSA expectations, GDPR obligations, and DORA’s resilience requirements.
Best Practices for Staying Compliant
Design once, comply many
For a medium‑sized fintech, the journey starts with a map. You document how card data enters, moves, and exits, across systems, services, and vendors. That data flow defines PCI scope, and scope drives cost and complexity. From there, you reduce scope deliberately. Tokenize by default. Lean on validated point‑to‑point encryption to keep sensitive data out of your hands. The less you touch card data, the simpler your control set, the lower your risk, and the smoother your audits.
Validation comes next
Decide whether your profile calls for a Self-Assessment Questionnaire (SAQ) or a full Report on Compliance (RoC). The right choice depends on transaction volume, architecture, and partner or scheme requirements. Over‑scoping creates unnecessary burden; under‑scoping creates expensive surprises. Once the route is set, you lock in the essentials and make them stick. Multi-Factor Authentication (MFA) on everything that matters. Enforced least privilege and strong joiner‑mover‑leaver processes. Patching Service level agreements (SLAs) that are observed rather than aspirational. Encryption in transit and at rest, with key rotation you can demonstrate. Centralized logging with retention aligned to policy. A secure software development life cycle (SDLC) that includes threat modelling for payment flows, code review criteria that target authentication, cryptography, and logging, and CI/CD gates that prevent misconfigurations from shipping.
Vendor diligence deserves the same rigor as your internal controls. Collect Attestations of Compliance (AOCs), review penetration test summaries, and where relevant, verify SOC2 or ISO27001 attestations. Make incident service level agreements and exit plans real, not just paragraphs in a contract. Maintain a single vendor risk register that shows, at a glance, which partners expose you most and what evidence you have on file. Testing and monitoring should be a steady rhythm rather than a Q4 scramble: quarterly ASV scans, annual penetration tests and segmentation checks, control health checks on a cadence, and a remediation backlog that burns down.
Training follows the same pattern
Short, frequent, role‑specific sessions will always beat marathon courses. Software engineers need secure coding refreshers. Support teams need reminders about masking and safe handling. Everyone benefits from phishing simulations that feel like your real inbox, not a staged exercise.
Incidents reveal your culture
Clear playbooks, known contacts, and a 24/7 escalation path are table stakes. Tabletop exercises that mirror real scenarios expose gaps you can close before they matter. Tickets, change records, code review notes, vulnerability scans, meeting minutes, configuration snapshots, and test reports form the audit trail that proves you’re not improvising. Auditors reward secure systems, but they also reward clean records and repeatable processes.
Common PCI Compliance Challenges
There are recurring pitfalls worth calling out. The first is the comforting fiction that if you don’t store card data, you’re out of scope. If you process or transmit it, you’re in scope, and logs, screenshots, and error traces can expand that scope faster than expected.
Another is shadow IT and SaaS sprawl. Without a disciplined inventory and strong single sign-on and MFA policies, it’s easy for an unvetted tool to wander into the wrong environment. Over‑customizing payment flows is another trap; the more bespoke code touches card data, the heavier your validation burden and the broader your attack surface. Change management can quietly sink you; a rushed hotfix can break a control you rely on without anyone noticing. And perhaps the most pervasive mistake is treating PCI like an annual sprint.
From the outside, customers and partners should see clarity and confidence. They should find plain‑spoken explanations of how you protect payment data and visible evidence of your validation. They should see thoughtful choices in cloud and vendor partners and trust that if incidents occur, communication will be transparent and timely. Most importantly, they should recognise a culture that treats security as part of the product, not an accessory.
Final Takeaway: Compliance is Protection
If there’s a single theme that ties this together, it’s discipline. PCI DSS gives EMIs a practical, battle‑tested framework which, when embedded with governance, GDPR privacy, and DORA resilience, yields a posture that is both defensible and efficient. One does not need exotic tooling to get there. You need scope minimisation, automation where it counts, rigorous testing, and meticulous documentation. The payoff is tangible. In a market where trust is earned one transaction at a time, that proof is a competitive advantage.
Compliance isn’t an annual event; it’s a continuous state of readiness. Treat it that way, and you won’t just pass audits; you’ll earn the confidence of customers, partners, and regulators, day after day.
