PCI DSS · Payment-data handling

PCI DSS and payment data in file transfers

Before sending a reconciliation file, ask which fields the recipient needs. Review a synthetic example with your payment security lead before choosing the transfer route.

Map the file’s journey

Identify where the report originates and where the receiving team will store it.

Assess the proposed scope

Have the payment security owner examine the systems, recipients and service providers involved.

Document the release decision

Keep the approved data fields and handling conditions with the workflow record.

Card-data scope
Skip the animation

Test a representative payment report

Inspect the report and its attachments for unnecessary account data. Have the responsible assessor review outstanding scope questions.

Can you remove the account data?

Use business references where they meet the need. Have the data owner review exports, attachments and screenshots before sharing. Do not assume masking alone removes a system from scope.

Is sensitive authentication data present?

Card verification codes, full track data and PIN blocks must not be retained after authorization, even if encrypted. Stop the workflow and follow your approved handling process.

Has the complete workflow been assessed?

If account data is necessary, involve your PCI lead or assessor. Review every system, recipient and service provider involved before approving the transfer route.

Encryption is
one control.
Scope is the
whole picture.

Look at the file’s entire journey. Discuss whether MX is suitable for the specific information and environment before sending payment data.

Stored information
Review what is retained, where it resides, who can access it and how it is deleted when no longer required.
Data in motion
Confirm the cryptography and security protocols protecting any account data sent over public networks.
People and permissions
Document the business need for each recipient. Include external users and administrative access in the review.
Supplier evidence
Request applicable assessment evidence and a clear allocation of responsibilities. A product demonstration is not a PCI assessment.

Show us the workflow.
Leave out the card data.

Use a synthetic example to explain the business need, your proposed recipients and the boundaries set by your PCI team. We can explore the file-exchange requirements together.

Discuss your exchange requirements

A few important
distinctions.

Is MX certified as PCI DSS compliant?

This page does not assert a PCI DSS validation for MX. Ask the team for current, applicable evidence and confirm the assessed service scope with your PCI lead before using it for account data.

Does encrypting a file remove it from PCI DSS scope?

Do not assume that it does. Encryption is a protection measure, not a general exemption. Your environment, data flows and ability to affect account-data security determine the assessment.

Can we store a card verification code in an encrypted file?

Not after authorization. PCI DSS prohibits retention of sensitive authentication data after authorization, including card verification codes, even when encrypted.

Is PCI DSS only relevant to the US?

No. PCI DSS is a payment-industry standard used globally. Both UK and US organizations should establish their obligations with the relevant payment partners and assessors.