Securing payment systems: from card data to instant payments.

Protecting card data

The Payment Card Industry Data Security Standard (PCI DSS) sets the baseline for protecting card data. It is written by the PCI Security Standards Council, an industry body founded by the card schemes. It is not law: card schemes and acquiring banks require it by contract, and the standard itself says local law prevails where the two conflict.

Versions. Version 4.0 was published in March 2022 and version 4.0.1, a limited revision, in June 2024. Requirements that were best practice until 31 March 2025 are now mandatory.

The twelve requirements, grouped under six goals:

• Secure networks and systems: network security controls; secure configurations.
• Protect account data: protect stored account data; use strong cryptography when sending card data over public networks.
• Manage vulnerabilities: protect against malicious software; develop and maintain secure systems and software.
• Control access: restrict access to those who need it; identify users and authenticate access; restrict physical access.
• Monitor and test: log and monitor all access; test security regularly.
• Policy: support security with organisational policies and programmes.

What is protected. The standard separates two kinds of data:

• Cardholder data: the card number (primary account number, or PAN), the cardholder's name, the expiry date and the service code. The PAN is what makes data cardholder data.
• Sensitive authentication data: the full magnetic stripe or chip data, the card verification code, and PINs.

The golden rule: sensitive authentication data "must not be stored after authorization, even if encrypted", apart from narrow exceptions for card issuers. The Council explains that stored codes could be combined by attackers with card numbers stolen elsewhere. A merchant does not need the security code for recurring or card-on-file payments.

Scope. The standard covers the cardholder data environment: every system, person and process that stores, processes or transmits card data, plus anything connected to it or able to affect its security. The standard's own examples include payment gateways and fraud monitoring systems, so the systems that watch transactions must be secured as carefully as those that process them.

Tokens, encryption and secure hardware

The best way to protect card data is often not to have it.

Tokenisation. The PCI Council defines tokenisation as replacing the card number with a substitute value, a token; turning the token back into the number is de-tokenisation. Systems that hold only tokens can fall outside much of the standard's scope, though the Council stresses that tokenisation does not remove the need to comply. The token vault, where tokens are linked back to real numbers, becomes the most attractive target and needs the strongest protection. A "token" that is simply the encrypted card number is still a card number and stays in scope.

Payment tokens. EMVCo, the card industry's technical body, describes EMV payment tokens that replace the card number and are restricted in how they can be used, for example to one merchant, one device or one type of payment. A token stolen from one merchant is useless elsewhere.

Point-to-point encryption (P2PE). The PCI Council's P2PE standard protects card data cryptographically from the moment the merchant accepts the card to a secure point of decryption, so the data is unreadable on the merchant's systems in between. Merchants using listed P2PE solutions have fewer requirements to meet.

Hardware security modules (HSMs). In the PCI glossary's terms, an HSM is "a physically and logically protected hardware device" offering secure cryptographic services, used for managing keys and decrypting account data. HSMs hold the keys that protect PINs and card data, so the keys never appear in ordinary computer memory.

PIN security. The PCI PIN Security Standard covers the secure management, processing and transmission of PINs and of the cryptographic keys that protect them, across the whole key life cycle: creation, transfer, loading, use and administration.

Validated cryptographic modules. Outside the card industry, the US and Canadian governments validate cryptographic modules against FIPS 140-3 (2019), which defines four increasing security levels. Banks often use it as a benchmark for HSMs.

The principle: reduce where sensitive data exists, make what remains unreadable, and keep the keys in hardware built to protect them.

Securing connections to payment networks

The SWIFT Customer Security Programme. SWIFT, the member-owned cooperative that runs the main international messaging network between banks, operates a Customer Security Programme. At its core is the Customer Security Controls Framework (CSCF), which has three objectives:

• Secure your environment;
• Know and limit access;
• Detect and respond.

The framework has mandatory controls, a baseline every user must implement on its local SWIFT infrastructure, and advisory controls, recommended practice. Any control that becomes mandatory starts life as advisory. Each year, every user must attest to its compliance, supported by an independent assessment, which internal compliance, risk or audit teams may carry out. A new version takes effect each July, and the attestation deadline is 31 December.

The international payments community tightened endpoint security after a series of frauds through banks' payment messaging systems in 2016, which the advanced course on payment infrastructure attacks covers in detail.

ISO 20022: richer, structured data. International payment messages have moved to the ISO 20022 standard. SWIFT ended the coexistence period between the old message format and ISO 20022 for cross-border payment instructions in November 2025, and says that after November 2026 only fully structured or partly structured postal addresses will be accepted.

Structured data matters for security and screening. The FATF's standard on payment transparency says payment information should be structured where possible in line with standards such as ISO 20022. The Wolfsberg Group, an association of global banks, says structured formats improve data quality and therefore transaction monitoring and screening outcomes. A name and address in separate, labelled fields can be screened far more reliably than a block of free text.

Securing open banking APIs

Open banking lets customers allow licensed third parties to access their accounts or start payments through application programming interfaces (APIs). That creates new doors into the bank, which must be secured.

The EU's rules. The EU's technical standards on strong customer authentication and secure communication (Delegated Regulation 2018/389, applying since September 2019) require:

• transaction monitoring to detect unauthorised or fraudulent payments, considering at least compromised credentials, the amount, known fraud scenarios, signs of malware and abnormal device use;
• interfaces that let third-party providers identify themselves securely, using qualified certificates under the EU's eIDAS framework;
• secure encryption throughout each session, short sessions, and credentials that no staff member can read at any time;
• a dedicated interface with the same availability and performance as the bank's own customer channels, with published statistics;
• limits on how often a provider can access account information without the customer present, at most four times in 24 hours unless agreed.

The FAPI 2.0 security profile. The OpenID Foundation, a non-profit standards body, finalised the FAPI 2.0 Security Profile in February 2025, a security profile for high-value APIs built on the OAuth 2.0 framework. Among other things it requires:

• sender-constrained tokens, so a stolen access token cannot be used by someone else;
• only confidential clients, able to keep their own secrets;
• authorisation codes that expire within 60 seconds.

Its attacker model sets clear goals: no attacker can access resources other than their own, no attacker can log in as another user, and sessions cannot be hijacked or swapped.

The lesson: an API is a payment channel. It needs strong identity for both sides, encryption, monitoring for fraud, and limits on what each party can do.

Instant payments raise the stakes

The EU's Instant Payments Regulation, (EU) 2024/886, requires payment providers that offer credit transfers to offer instant ones as well, available 24 hours a day on every day of the year. The receiving provider must credit the payee within 10 seconds of receiving the payment and confirm it; if no confirmation arrives in time, the payer's account is restored. Euro-area banks had to be able to receive instant payments by January 2025 and send them by October 2025, with later dates for other institutions and countries.

Why it changes security:

• There is no overnight batch in which to spot a problem. Fraud detection and screening must work in real time, within seconds.
• Money may be gone before anyone looks, so the regulation's recitals call for robust, up-to-date fraud detection and prevention.
• Customers can set daily or per-payment limits, a simple but powerful control.
• The regulation also requires Verification of Payee before the payer authorises, to catch misdirected and many fraudulent payments.

Bringing it together for any payment system:

• minimise and tokenise sensitive data, and keep keys in secure hardware;
• secure every connection to payment networks and APIs, with strong identity and encryption;
• treat fraud monitoring and screening systems as part of the protected environment;
• design monitoring and screening to work at the speed of the payment;
• test regularly, and report incidents quickly.

In Kenya: the Central Bank of Kenya's 2017 cybersecurity guidance for banks makes the board and senior management responsible for cybersecurity strategy, sets out the role of a chief information security officer, and requires banks to notify the Central Bank within 24 hours of significant cyber incidents. Its 2019 guideline for payment service providers makes the board ultimately responsible, requires annual penetration testing and twice-yearly vulnerability assessments, and requires notice within 24 hours, or 2 hours for systemically important payment systems. The Computer Misuse and Cybercrimes Act, 2018 requires attacks and intrusions to be reported to the National Computer and Cybercrimes Co-ordination Committee within 24 hours, and 2024 regulations list banking and payment transactions among critical sectors whose incidents must be reported within 24 hours. The Central Bank invited comments on revised guidance in 2026; check the current versions.

Your certificate of completion

Enter your name as you want it to appear, then save the certificate as a PDF. In the print window, choose Save as PDF. A certificate is issued once per completion of the course.

Saolix does not record who takes this course, so it cannot verify these certificates. The certificate confirms completion of a free self-paced course and is not an accredited qualification.