Payment Standards & Compliance Advisory

Overview

Why Standards Compliance Is Existential for Payment Businesses

Payment businesses operate within an interlocking web of mandatory standards. PCI DSS governs cardholder data security; EMVCo specifications define chip, contactless and 3DS interoperability; ISO standards underpin message formats and QR encoding; SWIFT governs correspondent banking messaging. Failure to comply with any one of these frameworks can result in scheme fines, loss of acquiring or issuing licences, reputational damage, and in some cases criminal liability for executives.

The landscape is further complicated by the pace of change: PCI DSS v4.0 introduced 64 new future-dated requirements now fully mandatory; EMV 3DS specification 2.3.1 significantly revised the authentication flow; ISO 20022 is displacing legacy SWIFT MT messages across the global correspondent banking network. FinPay Consultants provides current, practitioner-led advisory across all four pillars of payment standards compliance.

Our standards advisory covers four primary domains:

PCI DSS — the global baseline for cardholder data security, mandatory for any entity that stores, processes or transmits cardholder data.
EMVCo — the specifications governing chip, contactless, 3-D Secure and QR payment interoperability, maintained jointly by the six founding schemes.
ISO Standards — ISO 8583 (financial messaging), ISO 20022 (next-generation messaging) and ISO 18004 (QR code encoding for EMV QR).
Open Banking & Regulatory Frameworks — PSD2/PSD3, UK Open Banking, and DORA for EU financial entities.

PCI DSS

PCI DSS v4.0 — Full Compliance Advisory

PCI DSS v4.0: The 12 Requirements at a Glance

PCI DSS v4.0, the only active version since March 2024, organises its security controls into 12 top-level requirements across six goals:

Req 1–2 — Build and maintain a secure network and systems (firewall configuration, default credentials)
Req 3–4 — Protect stored account data and protect cardholder data with strong cryptography in transit
Req 5–6 — Maintain a vulnerability management programme (anti-malware, secure development)
Req 7–9 — Implement strong access control measures (need-to-know, authentication, physical security)
Req 10–11 — Regularly monitor and test networks (logging, intrusion detection, pen testing, vulnerability scans)
Req 12 — Maintain an information security policy covering all personnel and service providers

v4.0 introduced a Customised Approach allowing mature organisations to satisfy the intent of any requirement using alternative controls, subject to documented targeted risk analysis (TRA) and QSA acceptance. It also mandated MFA for all CDE access, strengthened e-commerce script integrity requirements, and introduced 64 future-dated requirements now fully in force.

SAQ Types: Which Applies to You?

Self-Assessment Questionnaires are available to merchants and eligible service providers whose card acceptance environment fits one of six defined profiles:

SAQ Type	Acceptance Channel	Typical Profile	Requirements
SAQ A	Card-not-present; all CHD functions fully outsourced to PCI DSS-compliant third party	E-commerce with fully-hosted payment page; no CHD on merchant systems	22
SAQ A-EP	E-commerce; payment page sourced from third party but merchant controls redirect	E-commerce using partial redirect or iFrame where merchant controls the redirect URL	191
SAQ B	Imprint-only or standalone dial-out terminals; no electronic CHD storage	Low-volume face-to-face merchants with standalone non-IP terminals	41
SAQ B-IP	Standalone IP-connected PTS-approved POI; no electronic CHD storage	Merchants using approved IP-connected terminals not connected to other systems	83
SAQ C	Payment application systems connected to internet; no electronic CHD storage	Merchants with internet-connected POS or payment application	160
SAQ D (Merchant)	All other merchant environments not covered above	Merchants storing, processing or transmitting CHD electronically in custom environments	329
SAQ D (Service Provider)	All eligible service providers	Third-party service providers handling CHD on behalf of others	340

ROC vs. SAQ — Scope Determination for Issuers, Acquirers and Gateways

A Report on Compliance (ROC) conducted by a Qualified Security Assessor (QSA) is mandatory for Level 1 merchants (over 6 million Visa/Mastercard transactions annually), all Level 1 service providers, and all entities directly connected to the scheme network (issuers, acquirers, payment gateways). SAQ validation is only available to lower-volume merchants and service providers meeting specific eligibility criteria. FinPay Consultants performs formal scope determination assessments to identify the correct validation path and the boundaries of the cardholder data environment.

Network Segmentation, Tokenisation & P2PE as Scope-Reduction Strategies

Three primary strategies reduce PCI DSS scope for payment businesses:

Network segmentation — isolating the CDE from out-of-scope systems using firewalls, VLANs or micro-segmentation. Segmentation must be validated by annual penetration testing and is not a PCI DSS requirement, but dramatically reduces compliance effort and cost.
Tokenisation — replacing the PAN with a scheme or gateway token throughout the post-authorisation lifecycle. When implemented correctly, tokenised environments remove the PAN from merchant and processor systems entirely, reducing scope to the tokenisation service boundary.
P2PE (Point-to-Point Encryption) — encrypting cardholder data at the POI device before it enters the merchant environment. A PCI-validated P2PE solution reduces merchant validation to SAQ P2PE (35 requirements) from SAQ D (329).

QSA vs. ISA — When to Use Each

A Qualified Security Assessor (QSA) is a PCI SSC-certified external organisation that conducts ROC assessments for entities required to undergo external validation. An Internal Security Assessor (ISA) is a trained employee of the assessed organisation who can perform internal PCI DSS assessments and support SAQ completion — but cannot sign a ROC. Large organisations with mature compliance programmes benefit from building an ISA capability for continuous compliance monitoring, supplemented by QSA engagement for formal validation cycles.

EMVCo

EMVCo Standards

EMVCo, the organisation jointly owned by American Express, Discover, JCB, Mastercard, UnionPay and Visa, maintains the global specifications for chip, contactless, 3-D Secure and QR payments. Compliance with EMVCo specifications is mandatory for any entity developing or certifying payment terminals, cards, or digital authentication services.

EMV Chip: Specifications 4.3 / 4.4

The EMV Integrated Circuit Card Specifications (Book 1–4) define the electrical interface, application selection, transaction processing and card/terminal interaction for contact chip payments. Version 4.3 introduced enhanced offline data authentication features; version 4.4 further aligned with contactless transaction flows and introduced the Kernel C-7 (UnionPay) specification. FinPay Consultants advises on EMV chip profile design — covering Application Interchange Profile (AIP), Application File Locator (AFL), CVM lists, Issuer Action Codes (IAC) and Floor Limit configuration for both contact and dual-interface card products.

EMV Contactless: Books A / B / C / D

EMVCo Contactless Specifications are structured across four books: Book A (architecture and general requirements), Book B (entry point — the kernel selection and transaction pre-processing layer), Book C (kernel specifications, with separate supplements per scheme kernel: C-2 Mastercard, C-3 Visa, C-4 Amex, C-5 JCB, C-6 Discover, C-7 UnionPay), and Book D (consumer device CVM, covering device-based cardholder verification for mobile wallets). Acquirers and terminal manufacturers must certify each applicable kernel independently through scheme-specific L2 and L3 programmes.

EMV 3-D Secure: Specification 2.3.1

EMV 3DS 2.3.1 defines the authentication protocol used by issuers, card schemes and merchants to authenticate cardholders in e-commerce transactions without redirecting them out of the merchant environment (frictionless authentication) or by presenting a challenge (step-up authentication). The specification defines the roles and responsibilities of the three core components:

3DS Server (3DSS) — operated by the merchant or PSP; assembles the authentication request message (AReq) and communicates with the Directory Server.
Directory Server (DS) — operated by the card scheme; routes authentication requests to the correct issuer ACS and returns the authentication response.
Access Control Server (ACS) — operated by the issuer; performs risk-based authentication, delivers frictionless decisions or challenge flows, and generates the cryptographic Authentication Value (AV).

EMV QR: Consumer-Presented vs. Merchant-Presented

The EMVCo QR Code Specification defines two modes for QR-based payments:

Consumer-Presented Mode (CPM) — the consumer displays a QR code on their mobile device containing payment credential data; the merchant's terminal or POS scans and decodes the QR to initiate a transaction. CPM is analogous to NFC contactless from a transaction flow perspective.
Merchant-Presented Mode (MPM) — the merchant displays a static or dynamic QR code; the consumer scans with their mobile wallet application. MPM is widely deployed across APAC markets (PayNow, PromptPay, BHIM UPI) and Middle East domestic schemes. FinPay Consultants advises on EMV QR implementation for both modes, including QR data format compliance, scheme-specific extensions and interoperability testing.

ISO Standards

ISO Standards for Payment Messaging

ISO 8583: 1987 / 1993 / 2003 Editions

ISO 8583 defines the message format for financial transaction card-originated messages — the basis for the authorisation, clearing and reversal messages exchanged between acquiring hosts, scheme networks and issuer hosts. Three editions are in active use:

ISO 8583:1987 — the original edition; still used by some domestic schemes and legacy switch environments. Defines a fixed set of data elements and a 64-bit primary bitmap.
ISO 8583:1993 — extended to 128 data elements (secondary bitmap); widely used by Visa VisaNet and early Mastercard BANKnet implementations.
ISO 8583:2003 — introduced tertiary bitmap support (192 data elements), XML message representation, and revised data element definitions. Adopted by Mastercard's current implementation and recommended for new scheme development.

FinPay Consultants advises on ISO 8583 host integration — covering MTI structure, bitmap decoding, DE-level field mapping, DE55 ICC data encoding (BER-TLV format), and scheme-specific extensions that diverge from the base standard.

ISO 20022: Message Catalogue and CBPR+ Subset

ISO 20022 is the global standard for financial messaging, providing a methodology for developing message standards using a common data dictionary and XML/JSON message syntax. The full ISO 20022 message catalogue covers payments, securities, trade finance, foreign exchange and cards. For payments, the key message families are:

pain (Payment Initiation) — pain.001 (Customer Credit Transfer Initiation), pain.002 (Payment Status Report), pain.008 (Direct Debit Initiation)
pacs (Payment Clearing and Settlement) — pacs.002 (FI to FI Status), pacs.004 (Return), pacs.008 (FI Credit Transfer), pacs.009 (Financial Institution Credit Transfer)
camt (Cash Management) — camt.053 (Bank to Customer Statement), camt.054 (Debit/Credit Notification), camt.056 (FI to FI Payment Cancellation)

The CBPR+ (Cross-Border Payments and Reporting Plus) initiative, led by SWIFT, defines a usage guideline subset of ISO 20022 for cross-border payments and cash reporting, mandating a phased migration from legacy SWIFT MT messages. The coexistence period (MT and ISO 20022 in parallel) extends through November 2025, after which MT messages will be retired for cross-border payments. FinPay Consultants advises on ISO 20022 migration strategy, message transformation layer design, and CBPR+ compliance.

ISO 18004: QR Code Encoding for EMV QR

ISO/IEC 18004 defines the QR code symbol specification — the underlying encoding standard used by EMV QR implementations. Payment-specific considerations include error correction level selection (Quartile or Higher recommended for payment QR codes to ensure scan reliability in variable lighting conditions), character set restrictions (Numeric or Alphanumeric mode for EMV QR payload compatibility), and maximum version selection to balance data density with scan performance on consumer device cameras.

Open Banking

Open Banking & Regulatory Frameworks

PSD2 / PSD3: PISP, AISP, SCA and eIDAS Certificates

The revised Payment Services Directive (PSD2) created two new regulated payment service categories: Payment Initiation Service Providers (PISPs) — entities that initiate payment orders from the payer's account held at another PSP — and Account Information Service Providers (AISPs) — entities that provide consolidated account information from accounts held at multiple PSPs.

Both PISPs and AISPs must use eIDAS qualified certificates (QWAC for transport layer authentication; QSealC for message signing) issued by a Trust Service Provider on the EU Trust List to identify themselves to Account Servicing Payment Service Providers (ASPSPs) in API calls. PSD3, expected to enter force in 2025–2026, will consolidate PSD2 into a directly applicable Regulation (PSR), strengthening open banking access rights, improving PISP/AISP technical access conditions, and introducing data sharing beyond payment accounts.

UK Open Banking: OBIE Standards and FAPI Security Profile

The UK Open Banking ecosystem is governed by the Open Banking Implementation Entity (OBIE) standards, which define API specifications for Account Information, Payment Initiation and Confirmation of Funds services. UK Open Banking mandates the Financial-grade API (FAPI) 1.0 Advanced security profile — a security profile built on OAuth 2.0 and OpenID Connect, requiring Pushed Authorisation Requests (PAR), JWT-secured authorisation response (JARM), mTLS certificate-bound access tokens, and PKCE. FinPay Consultants advises TPPs and ASPSPs on FAPI implementation, OBIE directory registration, and conformance testing.

DORA (EU): Digital Operational Resilience for Financial Entities

The Digital Operational Resilience Act (DORA), applicable from January 2025, establishes binding ICT risk management, incident reporting, operational resilience testing and third-party ICT risk management requirements for all EU financial entities — including payment institutions, EMIs and credit institutions. DORA requires a documented ICT risk management framework, mandatory reporting of major ICT incidents to competent authorities within defined timelines, annual resilience testing (TLPT — Threat-Led Penetration Testing — for significant entities), and register-of-information reporting for all critical ICT third-party providers.

Frequently Asked Questions

PCI DSS (Data Security Standard) addresses the security of cardholder data in storage, processing, and transmission broadly — it applies to any entity that stores, processes, or transmits PAN data. PCI PIN (PIN Security Standard) is a separate, narrower standard governing the management of PIN data and the cryptographic keys used to protect it. PCI PIN applies specifically to organisations that encrypt, decrypt, or translate PINs in an ATM or POS environment — acquirers, their PIN-accepting terminals, and any third-party processor handling PIN blocks. PCI PIN mandates HSM-based key management, dual-control and split-knowledge key loading, and defined procedures for key generation, distribution, and destruction. Both standards are assessed by PCI SSC-approved QSAs, but PCI PIN assessments require specific evaluator competency. Banks deploying ATM fleets or POS PIN acceptance must comply with both standards.

EMVCo publishes the foundational chip and contactless specifications — EMV Integrated Circuit Card Specifications (Book 1–4) for contact chip, and the Contactless Communication Protocol and Kernel specifications for contactless. These define the base interoperability layer. Visa and Mastercard then publish their own implementation specifications (Visa's VIS/qVSDC and Mastercard's M/Chip and PayPass/Tap & Go) which extend EMVCo with scheme-specific requirements — additional tags, mandatory data objects, and defined behaviour for issuer scripts, risk management parameters, and CVM processing. Terminals and cards must comply with both EMVCo base specs and the specific scheme implementation spec for each scheme they support. Certification (MTIP for Mastercard, ADVT for acquirer-side) validates the implementation against the scheme's specific requirements, not just the EMVCo base spec.

Migration timing depends on the regulatory and scheme mandates affecting your market. SWIFT's cross-border payments have mandated ISO 20022 (via CBPR+) from November 2022, with a co-existence period running until November 2025. Many central banks and RTGS systems are mandating ISO 20022 for high-value payments — the UK's CHAPS, the Eurosystem's TARGET2, and numerous APAC central bank systems have completed or are in active migration. For domestic card scheme messaging, ISO 8583 remains dominant and no major scheme has announced a migration deadline; however, ISO 20022 is increasingly used for reporting, dispute messaging (chargeback flows), and B2B payment instructions. Organisations should begin gap analysis and field mapping exercises now even if formal migration is not imminent, as legacy ISO 8583 parsing logic often contains undocumented edge cases that surface only under the structured scrutiny of ISO 20022 migration projects.