PCI DSS scope follows payment account data—not the TMS label

Trace account data before drawing the boundary

Treasury architecture can touch card-related receipts, payouts, merchant services, virtual cards, bank files, processors, ERP records, reconciliation platforms, and support workflows. Scope cannot be inferred from the product category. Teams need to trace whether payment account data is stored, processed, transmitted, displayed, logged, backed up, exported, or accessible through connected systems and people.

The record should name the data elements, source, purpose, flow, environment, trust boundary, user and service access, retention, masking or tokenization, and evidence date. A diagram should be testable against configuration and traffic. If a vendor changes an integration or support path, the scope decision should reopen without silently rewriting earlier assessments.

Segmentation and outsourcing require evidence

A processor, bank, gateway, or service provider can perform material work, but outsourcing does not make the buyer’s responsibilities disappear. Contracts, responsibility matrices, attestations, configuration reviews, access evidence, incident terms, and operating tests should identify what each party does and what remains in the customer environment.

Segmentation or tokenization may reduce exposure only when the actual implementation supports that conclusion. A product demonstration should include a support session, log export, failed transaction, exception queue, backup, administrator path, and downstream reconciliation. Buyers should test whether the supposedly out-of-scope component can still affect or reach the account-data environment.

Treasury controls extend beyond PCI DSS

PCI DSS focuses on payment account-data security. Treasury also needs authority, beneficiary validation, approval, segregation, sanctions and other screening where applicable, funding, liquidity, accounting, reconciliation, fraud response, recall, evidence retention, and continuity. A PCI assessment does not decide whether a payment was authorized, correct, compliant, or economically appropriate.

Systems should keep these control purposes distinct while connecting their evidence. A payment can pass technical security controls and still be misdirected or unauthorized; a fraud-control exception does not automatically establish a PCI failure. Product scorecards should avoid turning one standard into a universal payment-control badge.

Assessment evidence is scoped and dated

A questionnaire, attestation, assessment report, or provider statement has a defined entity, environment, role, period, version, and set of assumptions. Buyers should verify whether it covers the service, geography, integration, and account-data flow they plan to use. They should also identify changes and incidents that require review before the next cycle.

Treasury Operations Review uses the Council’s public record to frame the scope question, not to issue a compliance or security conclusion. Applicable payment-ecosystem obligations and assessment methods require current authoritative materials and qualified review. No standard can guarantee that compromise, fraud, interruption, or loss will not occur.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Treasury Operations Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.