Payment Processing
PCI DSS, card brand rules, and money transmission
Payment processors handle sensitive cardholder data under strict PCI DSS requirements and card brand rules. Thalorin streamlines payment compliance with automated evidence collection, scope reduction documentation, and continuous monitoring that maintains security between annual assessments.
Payment processing sits under PCI DSS v4.0.1, and as of 2026 the transition relief is gone: the 51 requirements designated future-dated when v4.0 published became mandatory on 31 March 2025, and v4.0.1 is the only active version. Every assessment now tests the full standard.
Processors and service providers carry a heavier version of this than merchants. Service provider requirements are more demanding, validation is generally annual via a Report on Compliance, and the Attestation of Compliance you issue becomes a document your customers rely on to scope their own assessments — which makes the responsibility matrix behind it a commercial artifact as well as a compliance one.
PCI DSS is also not the whole surface. Organisations handling PIN data fall under PCI PIN, point-to-point encryption solutions under PCI P2PE, and card brand operating rules impose obligations that sit outside the DSS entirely. ACH participants carry Nacha Operating Rules, which include their own security requirements.
Thalorin models the cardholder data environment as an explicit boundary and carries the customer-facing responsibility matrix from the same control state, so what you attest to and what you actually operate are the same object.
Financial institutions operate under intense scrutiny
Service provider requirements are stricter
Requirements that are recommended or scoped down for merchants are mandatory for service providers, and validation expectations are higher. A merchant-oriented reading of the standard understates the obligation.
Your AOC scopes your customers' assessments
Customers rely on the responsibility matrix behind your Attestation of Compliance to scope their own. Ambiguity there becomes their audit finding and your support burden.
PCI DSS is not the only PCI standard
PIN, P2PE, and card production standards apply to specific activities, and card brand operating rules sit outside PCI entirely. Programmes scoped to the DSS alone miss obligations.
Segmentation must survive testing
Where segmentation reduces scope it must be validated by penetration testing. A boundary that testing traverses expands the assessment mid-engagement, usually at the worst time.
How Thalorin helps
PCI DSS compliance automation
Model the cardholder data environment explicitly, classifying connected-to and security-impacting systems rather than inferring scope.
Card brand rule tracking
Track PCI DSS v4.0.1 across all twelve requirement areas, including requirements mandatory since 31 March 2025.
Scope reduction documentation
Generate the customer-facing responsibility matrix from the same control state the assessment reads.
P2PE compliance support
Carry PCI PIN, P2PE, and card brand obligations alongside the DSS where the activity triggers them.
Third-party service provider management
Maintain segmentation validation evidence supporting the scope claim it underwrites.
Incident response for payments
Track Nacha Operating Rules obligations for ACH participation as part of the same programme.
Payment Processing: common questions
Are we a merchant or a service provider under PCI DSS?
A service provider is an entity that stores, processes, or transmits cardholder data on behalf of another entity, or that could affect the security of another entity's cardholder data. Many organisations are both — a merchant for their own sales and a service provider for their customers — and the service provider requirements are the stricter set, so the dual classification generally drives the programme.
What does our Attestation of Compliance actually commit us to?
It states which requirements you validated and, through the accompanying responsibility matrix, which obligations you meet versus which remain with your customer. Customers scope their own assessments from that matrix, so vague or over-broad language creates downstream findings for them and support load for you. It is worth treating as a carefully drafted commercial document.
Do the future-dated requirements still have a grace period?
No. The 51 requirements designated future-dated when v4.0 published in March 2022 became mandatory on 31 March 2025, and the v4.0.1 release did not change that date. Any assessment from that point forward tests them as ordinary requirements.
Does P2PE remove us from PCI DSS scope?
A validated PCI P2PE solution can substantially reduce merchant scope, because encrypted data outside the solution's decryption environment is not treated as cardholder data for scoping. It does not eliminate the obligation, and the reduction depends on using a validated solution correctly — a non-validated encryption implementation does not achieve the same scope effect.
How do Nacha rules relate to PCI DSS?
They are separate regimes for separate rails. PCI DSS governs card data; Nacha Operating Rules govern ACH participation and include their own security requirements, including obligations around protecting bank account information. Organisations processing both card and ACH payments carry both, and the underlying controls overlap enough that shared evidence is worthwhile.
Regulatory state described as of August 2026. Requirements change; verify against the current rule before relying on any date above.
Talk to us about Payment Processing.
See how one evidence artifact satisfies Payment Processing requirements alongside every other framework you carry.