Category: Chargebacks and Disputes

TC15 Dispute

Also known as: TC15, TC15 chargeback, TC15 transaction code, TC15 message

Simply put

A TC15 is a Visa transaction code used to record disputes, commonly known as chargebacks, when a cardholder or their issuing bank challenges a transaction. It can cover many kinds of disputes, including problems with a product, authorization issues, and processing errors. Merchants and acquirers track TC15 activity because it can affect their standing under Visa's dispute-monitoring rules.

Formal definition

TC15 is a Visa transaction code that identifies dispute (chargeback) records processed through Visa's systems, generated when a transaction is disputed by a cardholder or the issuing bank. TC15 captures all dispute types, including product issues, authorization problems, and processing errors, and is distinct from TC40, which represents fraud reports or alerts. Under Visa's VAMP framework, the dispute ratio is calculated using total disputes comprising all TC40 fraud alerts and all TC15 records (including both fraud and non-fraud disputes), so every TC15 contributes to a merchant's or acquirer's VAMP metrics. TC15 messages are also used operationally in Visa's Rapid Dispute Resolution (RDR) process, where Visa sends a TC15 message identifying the transaction as an RDR transaction to the acquirer on behalf of the issuer, resulting in a refund. Because dispute and monitoring rules are governed by Visa's network rules and may change and vary by region, readers should confirm current thresholds, calculation methods, and program requirements against Visa's published rules.

Why it matters

The TC15 transaction code sits at the center of how Visa tracks and monitors disputes, so understanding it is essential for merchants and acquirers who need to manage their standing under Visa's dispute-monitoring programs. Because a TC15 record is generated whenever a cardholder or issuing bank challenges a transaction, TC15 volume is a direct reflection of dispute activity across a merchant's portfolio, spanning product problems, authorization issues, and processing errors rather than fraud alone.

Under Visa's VAMP framework, the dispute ratio is calculated using total disputes comprising all TC40 fraud alerts and all TC15 records, including both fraud and non-fraud disputes. This means every TC15 contributes to a merchant's or acquirer's VAMP metrics, so even disputes that have nothing to do with fraud can affect monitoring outcomes. Teams that treat TC15 records as a fraud-only signal may misjudge their exposure, since a rise in ordinary processing or product disputes can move the same ratio that fraud reports feed into.

TC15 also has an operational role beyond monitoring. In Visa's Rapid Dispute Resolution process, Visa sends a TC15 message identifying a transaction as an RDR transaction to the acquirer on behalf of the issuer, which results in a refund. Because dispute and monitoring rules are governed by Visa's network rules and may change and vary by region, teams should confirm current thresholds, calculation methods, and program requirements against Visa's published rules rather than relying on fixed figures.

Who it's relevant to

Merchant Risk and Dispute Teams

Merchant risk teams track TC15 activity because every TC15 record contributes to their VAMP metrics, whether the underlying dispute is fraud-related or not. Understanding that TC15 captures product, authorization, and processing disputes helps these teams see that reducing chargebacks requires attention to operational and service issues, not just fraud controls.

Acquirers and Payment Processors

Acquirers receive and process TC15 records on behalf of their merchants and must monitor how these records affect standing under Visa's dispute-monitoring rules. They also handle TC15 messages in the Rapid Dispute Resolution process, where Visa sends the message to the acquirer on behalf of the issuer to trigger a refund, so acquirers need to understand both the monitoring and operational roles of the code.

Fraud Analysts

Fraud analysts benefit from distinguishing TC15 from TC40: a TC15 is a chargeback record covering many dispute types, while a TC40 is a fraud report or alert. Because both contribute to the VAMP dispute ratio, analysts should avoid treating TC15 volume as a pure fraud indicator and should confirm how each record type is weighted under Visa's current rules.

Compliance and Program Managers

Those responsible for meeting Visa's monitoring program requirements need to confirm current thresholds, calculation methods, and program definitions against Visa's published rules, since dispute and monitoring rules are governed by network rules that may change and vary by region. TC15 records are a core input to these programs, making accurate interpretation important for compliance planning.

Inside TC15

TC15 record

A clearing record format historically associated with certain card networks used to transmit chargeback, representment, and related dispute information between processing entities. The exact record layout, usage, and lifecycle are governed by network-specific specifications, which vary by brand and region and change over time; confirm details against the current network documentation.

Dispute (chargeback) lifecycle

The sequence of messages by which a transaction is contested, potentially including the initial chargeback, representment (re-presentment) by the acquirer/merchant, and any further arbitration or pre-arbitration stages. These stages, their names, and time frames are defined by card brand and network rules and differ by network and region.

Reason code

A network-defined code indicating the basis for a dispute, such as fraud, authorization, processing errors, or cardholder disputes about goods or services. Reason code sets and their meanings are governed by each card network and are subject to change.

Participating parties

The issuer, cardholder, acquirer, and merchant, along with the networks that route dispute messaging. Roles and responsibilities in resolving a dispute are set by network operating rules.

Supporting data fields

Transaction identifiers and reference data (for example, amounts, dates, and transaction references) carried in the record to link a dispute to its originating transaction. Any cardholder data present must be handled under applicable data protection controls; sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, and PINs must not be retained after authorization.

Common questions

Answers to the questions practitioners most commonly ask about TC15.

Is a TC15 dispute the same thing as a standard chargeback?

No. A TC15 is a specific transaction record format used within certain clearing and settlement systems, whereas a chargeback is the broader dispute mechanism through which a transaction is reversed. The record type is a technical carrier for dispute-related information, not the dispute right itself. The rules governing whether a dispute succeeds are set by card brand and network rules, which vary by region and change over time. Confirm the precise handling against the current published network specifications rather than assuming the record format defines the dispute outcome.

Does receiving a TC15 mean the disputed transaction was necessarily fraudulent?

No. A dispute record can be raised for many reasons, including processing errors, cardholder recognition issues, first-party or friendly fraud, and genuine card-not-present or card-present fraud. The presence of a dispute does not by itself establish that criminal fraud occurred, and the underlying reason is indicated by codes defined in network rules. Distinguishing genuine fraud from first-party or chargeback-related disputes requires investigation, and classifications differ by card brand and region.

What data should be captured to respond to a TC15 dispute effectively?

Responses generally draw on transaction and authorization details and any supporting evidence permitted under network rules. Note that sensitive authentication data, such as full track data, card verification values, and PINs or PIN blocks, must not be stored after authorization even when encrypted, so it is not available to include. Cardholder data such as the PAN may only be retained under defined controls, and where displayed it is often truncated or masked. Confirm required and permitted evidence against the current network dispute rules.

How does PCI DSS scope apply to systems that handle dispute records?

Systems that store, process, or transmit cardholder data as part of dispute handling fall within PCI DSS scope, and applicable controls depend on the current published version of the standard. Requirement numbering and wording differ between versions, so confirm the specific requirements against the current standard rather than assuming a fixed number. Techniques such as tokenization, truncation, or masking may reduce scope, but their effect depends on implementation and validation, not on the label alone.

How can truncation or masking be used when displaying dispute data to analysts?

Displaying only a portion of the PAN through truncation or masking helps limit exposure of cardholder data during dispute review, while these techniques transform data differently and are not interchangeable with encryption or tokenization. Whether a given approach reduces PCI DSS scope depends on how it is implemented and validated. Ensure any full PAN retained for dispute purposes is protected under the applicable controls, and confirm handling against the current standard.

What operational trade-offs arise when automating dispute triage?

Automated triage of dispute records can help reduce manual effort, but detection and classification logic carries false-positive and false-negative trade-offs: legitimate disputes may be mishandled, and genuine fraud may be misclassified as first-party or friendly fraud, or vice versa. Time limits and evidence requirements are governed by network rules that vary by region and change over time. Automation is intended to support, not replace, review against the current network dispute rules, and outcomes should be confirmed against those rules.

Common misconceptions

A TC15 dispute record is a PCI DSS standard or requirement.

TC15 is a network clearing/dispute record format defined by card network specifications, not a PCI security standard. PCI DSS governs how any cardholder data within such records is protected, but it does not define the dispute record itself, and it is separate from PA-DSS, the PCI Software Security Framework, PCI PIN, PCI P2PE, and PCI 3DS.

Winning a representment or filing a dispute record eliminates fraud loss.

Dispute processing allocates liability according to card brand and network rules, which vary by region and change over time. It does not prevent fraud from occurring and may involve trade-offs; outcomes depend on evidence, reason code, and applicable network rules rather than any guarantee.

Dispute records can safely include full authentication data to prove a transaction was legitimate.

Sensitive authentication data (full track data, CAV2/CVC2/CVV2/CID, PINs and PIN blocks) must not be stored after authorization, even when encrypted. Only permitted cardholder data may be retained under defined controls, and even then should be truncated, masked, or otherwise protected as appropriate.

Best practices

Validate TC15 record structure, reason codes, and dispute time frames against the current card network specifications for each brand and region, rather than assuming a fixed format.

Ensure any cardholder data carried in dispute records is protected under applicable PCI DSS controls, and confirm the specific requirements against the current published standard version rather than relying on a fixed requirement number.

Never retain sensitive authentication data after authorization in dispute records or supporting evidence; apply truncation, masking, or tokenization to any stored PAN where full values are not required.

Treat dispute outcomes and liability shift as governed by evolving card brand and network rules that vary by region, and monitor rule updates that affect representment eligibility and evidence requirements.

Reconcile each dispute record to its originating transaction using network reference identifiers to reduce mismatches, and track false-positive and false-negative outcomes in your dispute handling process.

Coordinate dispute handling across issuer/acquirer, fraud, and compliance teams so that data-handling, evidence collection, and reason-code interpretation remain consistent and auditable.