Here’s the detail that catches founders off guard: PCI DSS v4.0 isn’t an upcoming deadline anymore. The transition period from the old version, 3.2.1, ended March 31, 2025. As of today, if your product stores, processes, or transmits cardholder data — or if your software touches a system that does — you’re not preparing for PCI DSS v4.0.1, you’re already required to be compliant with it. A lot of fintech teams are still operating like this is a future problem.
Note on sourcing
The primary example below is SDK.finance, a real fintech software platform provider, documented in their own published announcement with specific assessment dates and a named independent auditor. It’s cited and linked throughout. This is not a B4Q client engagement — it’s included because it’s a clean, verifiable, recent example of what a real PCI DSS v4.0.1 assessment looks like, including the parts most compliance content skips.
The Company: SDK.finance
SDK.finance builds a software platform that banks, payment service providers, and fintech companies use to build payment infrastructure on top of. Here’s the detail that makes this case study genuinely useful rather than generic: SDK.finance itself doesn’t store, process, or transmit cardholder data — that responsibility sits with the banks and PSPs actually running payment flows on their platform. But their software and development practices still fall inside their customers’ PCI DSS scope, which is exactly the kind of scoping nuance that trips up companies building payment-adjacent products.
The Problem: Compliance by Proxy
This is a scenario a lot of fintech infrastructure companies face without realizing it: you’re not the one holding cardholder data, so it’s tempting to assume PCI DSS isn’t your problem. It is. If a bank or PSP builds their compliant payment flow on top of your platform, your secure development practices, your change management process, your vulnerability handling — all of it becomes part of what their QSA has to evaluate when assessing them. A platform provider that can’t demonstrate its own PCI DSS-aligned practices becomes a liability sitting inside every one of its customers’ compliance programs.
Why the Timeline Actually Matters
The mechanics of the v4.0 transition are worth understanding precisely, because the deadline structure itself has already caught teams out. PCI DSS 4.0 introduced 64 new or updated requirements in total. Thirteen of those took effect immediately upon the standard’s adoption. The remaining 51 had a built-in grace period — but that grace period ended March 31, 2025, and every one of those 51 requirements has been mandatory since. There is no extension, and as of 2026 payment brands are actively enforcing against companies that haven’t made the transition.
The stakes for getting this wrong are concrete and immediate, not abstract: card brand fines for non-compliance typically range from $5,000 to $100,000 per month per acquirer until compliance is restored — and for an early-stage company, losing merchant processing rights entirely functions as an effective shutdown, not a fine you budget around.
What SDK.finance Actually Did
SDK.finance underwent a formal PCI DSS assessment conducted between October 1 and December 2, 2025 — recent enough to reflect the current, fully-enforced version of the standard rather than a legacy assessment grandfathered in under the old rules. The assessment specifically evaluated requirements tied to secure software development and information security governance — the parts of PCI DSS 4.0.1 that apply to a platform provider rather than a direct cardholder-data handler. According to the company’s own account, independent auditors confirmed that all applicable requirements were either in place or correctly scoped as not applicable.
Critically, the assessment was performed by 7Security GmbH, an independent Qualified Security Assessor — a named, real accredited firm, not a self-attestation or an internal claim. That distinction matters more in PCI DSS than in almost any other framework in this series: a PCI DSS attestation without a real QSA behind it isn’t worth the paper it’s printed on to a bank or acquirer evaluating a vendor.
A Second Data Point: Pyypl
Pyypl, a fast-growing fintech operating across Africa and the Middle East, achieved PCI DSS v4.0 certification specifically as a first mover in its region — according to CEO Antti Arponen, the company built its compliance framework from scratch for v4.0 rather than adapting existing v3.2.1 infrastructure. The business case Pyypl made publicly is worth citing directly: independent research cited by the company found PCI DSS-compliant organizations experience meaningfully fewer data breaches than non-compliant ones, and separate survey research found a majority of businesses report their PCI DSS compliance work directly improved customer trust and reputation. For a company operating across multiple regulated markets simultaneously, certification also had a practical operational benefit — streamlining the process of obtaining new licenses as they expanded into additional countries.
The Result
For SDK.finance, the outcome is straightforward but meaningful: customers building on their platform now inherit a foundation designed and maintained to PCI DSS-aligned principles, which reduces those customers’ own compliance risk during their audits and regulatory reviews. That’s the specific value a compliant infrastructure provider offers — not just its own clean bill of health, but a smaller compliance burden passed down to everyone building on top of it.
For Pyypl, certification translated into agility: the ability to expand into new markets and streamline new licensing processes specifically because the compliance foundation was already in place, rather than being rebuilt market by market.
The Pattern Underneath Both Stories
- 1. We don’t store cardholder data” doesn’t mean “PCI DSS doesn’t apply. SDK.finance’s situation — in scope through its customers’ compliance requirements rather than direct data handling — is far more common among fintech infrastructure and software companies than most founders assume going in.
- A named, accredited QSA is non-negotiable. Both companies’ credibility rests on being assessed by real, named accredited assessors — 7Security GmbH for SDK.finance, an unnamed but real QSA process for Pyypl. This is not a framework where a compliance dashboard alone gets you a defensible attestation.
- The deadline already happened. Every fintech-adjacent company still treating PCI DSS v4.0 as a future initiative rather than a current requirement is already out of compliance with 51 mandatory requirements, not preparing for them.
- Certification compounds outward. SDK.finance’s compliance reduces risk for its customers; Pyypl’s compliance accelerated its own market expansion. In both cases, the value extended past the company that actually got certified.
What This Means If You're Building a Payments Product Right Now
The first, most consequential decision is scoping: understanding precisely whether you handle cardholder data directly, whether you’re a service provider whose infrastructure sits inside someone else’s compliance boundary (SDK.finance’s exact position), or both. Getting this wrong in either direction is expensive — over-scoping means auditing systems that were never actually in the cardholder data environment, and under-scoping means missing requirements a QSA will catch later, at a worse time, in front of a customer or acquirer.
B4Q’s approach for a company in this position starts with exactly that scoping conversation — mapping where cardholder data actually flows, and where your platform sits relative to your customers’ compliance boundaries — before any control work begins. From there, the priority is closing gaps against the 51 requirements that have been mandatory since March 2025 first, since those are the ones actively being enforced right now, with a realistic assessment timeline built around whichever SAQ level or Report on Compliance your transaction volume and merchant/service-provider classification actually require.
The Honest Caveat
Neither SDK.finance nor Pyypl published hard before/after sales or revenue numbers tied specifically to PCI DSS v4.0 certification — the sourced outcomes here are about risk reduction and market access, not quantified deal acceleration the way some SOC 2 case studies report. That’s a real limitation of the available public data on this framework specifically, and it’s worth being honest that PCI DSS’s return on investment is often more about avoiding catastrophic downside (fines, revoked processing rights, breach liability) than accelerating a specific sales metric.