How TC40 Reports Affect Your Merchant Account: Monitoring and Response

A TC40 report is a Visa fraud-reporting record, not a chargeback decision or a notice that your merchant account has automatically failed monitoring. To assess account exposure, identify the reporting scope, reconcile the fraud and dispute records, and ask your processor which network program or contractual action applies.

This guide is for the merchant’s risk, payment-operations and finance teams responding to a fraud-report increase or an account notice. For report definitions and background, use our TC40 report explainer.

Confirm What the Report Describes

Card networks receive fraud information from issuing banks. TC40 is Visa terminology; do not label every Mastercard fraud record TC40. Ask your processor to identify the actual network, file type, reporting period and merchant identifier.

Legacy reporting references can use names such as System to Avoid Fraud Effectively (SAFE) or Visa’s Risk Identification Service (RIS). The latter Visa URL now redirects to Visa Protect for Banks. For Mastercard’s developer listing, see Fraud and Loss Database (FLD). These references do not replace the current file specification and monitoring terms supplied by your provider.

Separate the Fraud Signal, Dispute and Money

Stripe’s current monitoring guidance explains that Visa VAMP uses TC40 fraud data and TC15 dispute data, with program-specific exclusions. Its monitoring calculations can differ from a merchant dashboard. Do not calculate account exposure from chargebacks alone or silently collapse two report types into one event.

Build an Account-Response Worklist

The following is a suggested operational checklist, not a network-mandated reporting template. Start with your acquirer or processor’s notice, and assign an owner to every unresolved question.

Investigate the Cause Before Changing Controls

Group matched records by product, fulfillment route, customer complaint, billing descriptor and account. Check whether the increase reflects unauthorized payments, unclear billing, delivery problems, duplicate processing or a reporting mismatch. A fraud label alone does not prove the customer’s intent.

Use the relevant order, authentication, delivery, cancellation and communication records to select an action. Correct billing or fulfillment problems you confirm. For disputed payments, follow the actual case response process; for suspected reporting errors, send your processor the payment and report identifiers plus supporting records. Do not change a record simply to make the ratio look lower.

Respond to the Actual Account Notice

Ask the processor to confirm the program, threshold and regional scope, the period under review, any requested remediation, the response deadline and how completion will be assessed. Monitoring identification, a reserve change and a specific chargeback are separate events. A processor’s own risk requirements can differ from a network’s published thresholds.

For Visa, consult the current VAMP fact sheet and your provider’s implementation guidance. Mastercard has its own rules concerning excessive chargebacks; confirm the applicable current edition and program with your provider. Do not reuse another merchant’s threshold or deadline without checking scope.

Document the confirmed cause, control change, responsible owner, implementation date and evidence of completion. Track new report and dispute activity after the change using a consistent reporting period. A remediation plan should show what changed and how it will be measured rather than promise that all fraud will disappear.

Reconcile Results Without Confusing Recovery and Prevention

A won chargeback can recover funds without removing the original monitoring event. Stripe’s guidance says monitoring generally does not wait for dispute outcomes. Keep case-win and cash-recovery reporting separate from new fraud/dispute volume and program standing.

Use a daily work queue for new records and deadlines, a regular review of confirmed causes, and a monthly reconciliation to the official network/processor report. This is a suggested team cadence; follow any shorter deadline in the actual account notice.

TC40 and Merchant Account FAQs

Does a TC40 report automatically close a merchant account?

A TC40 record is not itself an account-closure decision. Check whether you received a fraud signal, formal monitoring identification or a processor account notice. The actual program rules and merchant agreement determine what happens next.

Should every TC40-linked payment be refunded?

Review the actual allegation, order status, customer communication and provider instructions. A blanket refund rule can create unnecessary losses or duplicate a refund already issued. Handle any active dispute through its own authorized response route.

What if the fraud report and dashboard do not match?

Preserve both records and their reporting periods. Reconcile the payment identifiers, account scope and event types, then ask the processor to explain or correct the discrepancy with supporting evidence.

Where should I start if I only need a TC40 definition?

Read the TC40 report explainer. This page focuses on the worklist and decisions needed to respond to merchant-account exposure.