Dispute cases

Overview

Customers can dispute transactions made on their card or their account for many reasons ranging from not recognizing the transaction to fraudulent transactions by an unauthorized user. The most common reasons for disputes are as follows:

• Amount discrepancy

• Duplicate/Unauthorized transaction

• Victim of fraud, card theft, or identity theft

• Returned merchandise (generally not covered by Reg E)

• Product/Service not as described or not received (generally not covered by Reg E)

When a customer notifies a FinTech about a dispute, the FinTech must have the ability to manage and resolve these disputes, in compliance with regulations as well as network rules:

• US regulations are strict when it comes to consumer transactions:

  • Regulation E applies to consumer debit transactions - it mandates issuance of provisional credit to the customer account while the dispute is under investigation

  • Regulation Z applies to consumer credit transactions - it mandates that a transaction that is under dispute is not included in the outstanding/due balances, and is not included in the available credit balance

  • These regulations also have strict timelines around customer notifications, which is ultimately the responsibility of the FinTech

  • There are no specific regulations around commercial transactions

• Card networks also have their own “zero liability” policies - cardholders won’t be held responsible for unauthorized charges made with their card or card information provided they promptly report the issue

Best practices

The dispute process is expensive for a FinTech as it carries potential loss of revenue, incurs network fees, and can add management overhead costs. For that reason, it is in the FinTech’s best interest to implement measures to avoid disputes.

The following are best practices for avoiding or resolving disputes:

• Only posted transactions can be disputed, and for card transactions only if within 120 days from the settlement. A pending transaction cannot be disputed.

• Before creating a dispute, advise the customer to contact the merchant directly to resolve the issue. If the issue cannot be resolved, a dispute can be initiated.

• Request supporting documentation, such as receipts or email communication with the merchant and timelines.

• When a card is reported lost, stolen, or compromised, immediately freeze the card to prevent unauthorized transactions.

• A dispute cannot exceed the amount of the original transaction.

• For card transactions, a dispute should not be submitted to the network if the disputed amount is below $25 (this is validated by the system).

When to use the Dispute case type

The Dispute case provides a place to track customer disputes of transactions that occur. Anytime a customer notifies a FinTech that they would like to dispute a transaction, whether the notification is via phone call, email, or other means in the FinTech's application, a Dispute case must be created. The Dispute case is used to track the dispute details, lifecycle and events that occur during the investigation into the dispute, including:

• Information about the disputed transaction, and reason for the dispute

• Documentation submitted with the dispute (evidence)

• Applicable regulations and timelines

• Dispute status, including dispute actions, dispute credit status, and resolution status

• Dispute-related postings, such as provisional credits, provisional credit reversals, and final credits

• Dispute history

• Related cases (other dispute cases for the same customer)

Dispute Investigation / Lifecycle

1. Initiate dispute:

   FinTech receives chargeback request from cardholder, and creates a dispute case on the Synctera platform, representing the issuer.

2. Initiate chargeback:

   Ground Control, Synctera’s Compliance Operations team, investigates the dispute and determines whether it is eligible for a chargeback. If eligible, Ground Control initiates a network chargeback by sending a notice to the acquiring bank through the card network.

3. First chargeback:

   The acquiring bank informs the merchant of the chargeback. The merchant reviews the chargeback information and decides whether to accept or dispute it.

4. Representment:

   If the merchant chooses to dispute the chargeback, they respond to the acquiring bank with evidence to support their case. The issuer is notified of the representment. Ground Control evaluates the merchant's response and decides whether to accept or dispute the representment.

5. Pre-arbitration (optional):

   Pre-arbitration is an optional step where the issuing bank and acquiring bank attempt to agree on the chargeback. If the issuer decides to dispute the representment and thereby uphold the chargeback, they do so by submitting a pre-arbitration request. The merchant can also request further review through pre-arbitration.

6. Pre-arbitration response:

   Assuming that the pre-arbitration request was submitted by the issuing bank, the merchant reviews the request and decides whether to accept the loss or dispute the request, in which case the chargeback goes to arbitration.

7. Arbitration:

   If the issuer disagrees with the merchant’s pre-arbitration response, they can take the case to arbitration with the network.

8. Resolution:

   The network (arbitrator) reviews the chargeback and makes a final decision. The decision is final and binding on both the merchant and the issuing bank.

Note that the above diagram does not reflect the compliance case, which is very rare:

• In the event that either the issuer or acquirer has violated network rules or the reason for dispute does not apply to one of the available reason codes, a compliance case can be raised with the network.

• A compliance case can be filed against a transaction by either party any time prior to the start of the chargeback dispute lifecycle. In the event that a chargeback dispute lifecycle has completed and either party believes that the transaction is valid for compliance the transaction can be sent to the network in a subsequent compliance case.

For more details about disputes, please refer to the Dispute Guide.

What's displayed for Dispute cases

Customer 

Users must Select Customer to search for the customer. 

You can search for the customer by name, phone number, email, or SSN. 

Account

Select the account accordingly. The account options will depend on the customer selection. If the customer has multiple accounts, ensure you select the account associated with the transaction that will be disputed. 

Transaction

Select the disputed transaction. The transaction options will depend on the account chosen. If you cannot find the transaction, ensure you selected the correct customer account and that the transaction has been posted. A pending transaction cannot be disputed.    

Card Possession and Merchant Name

The Merchant name will automatically populate based on the transaction selection. Select the Card Possession Status, either In Possession or Lost/Stolen. 

External case number

Used for linking the Synctera Dispute Case to other case systems where disputes are also being tracked and investigated. This field is optional. 

Date reported by customer

The date the customer contacted the Company to dispute the transaction. This calculates due dates for provisional credit, investigation completion, and Reg E related dates. The date defaults to the date the case was created. However, if the case is not opened when the customer contacts the Company, it must be updated. The date should be backdated to match if the customer contacted the Company outside business hours or left a voicemail. 

Important dates

Due dates indicate the dates to complete certain aspects of the investigation to meet Reg E timelines. Specifically the standard and extended Provisional Credit Deadlines and the standard and extended Investigation Completion Deadlines. These are auto-calculated based on the Date Reported by the Customer.

Dispute Amount

Used to store the amount the customer is disputing on the transaction. The dispute may be the entire transaction or a partial amount.

Dispute Type

The specific type of dispute the customer is opening, based on defined network dispute types (Fraud, Authorization, Processing, or Consumer).

• Fraud: A cardholder submits a fraud dispute when they see a transaction on their statement that they do not recognize, which can result from a lost or stolen card or a stolen PAN.

• Authorization: An authorization dispute typically occurs when there is a clearing transaction without authorization. In this scenario, the customer account balance may be negative. 

• Processing: A processing error dispute occurs when the transaction was expected, but data such as the transaction amount or account number are incorrect.

• Consumer: A consumer dispute occurs when the customer has a dispute with the merchant, such as a claim that incorrect or defective merchandise was received or that they did not receive the product/service. In this case, the customer demands their money back, and the merchant has refused.

Provisional credit info

Used to store the date and amount of any provisional credit provided to the customer, and if required, the date and amount of that provisional credit that was reversed at the final outcome of the investigation.

Final message date

Used to note the last contact date with the customer to ensure and have proof of compliance with Reg E timelines. Attach any evidence and communication with the customer to the case.

Reviewing and decisioning cases  

Submit case

Take this action when the initial information about the dispute has been gathered and entered into the Synctera Console. From there, the information will be relayed to Marqeta, who will be performing the investigation at the network level and providing updates and possibly requests for further information or documentation from the customer who opened the dispute.

Cancel case

In the scenario where the customer would like to cancel a dispute, the case can be canceled as well.

Mark complete

Take this action when a final decision has been made on the dispute and credit has been provided. This is a terminal state and should be used when the dispute has been confirmed as valid or not valid. Once the case is put into this state, there can be no further action taken.

Mark transaction as fraudulent

Take this action when it is determined by the investigation that the transaction being disputed was fraudulent. This will update the transaction fraud model and notify it that the transaction was fraudulent, helping the model to learn that those types of transactions for the customer should be considered fraud going forward.