This content has been archived.
Close popover

Smart Dispute and Visa Claims Resolution (VCR) functional overview

In late 2015, Visa announced its new dispute process, Visa Claims Resolution (VCR). All card issuers, acquirers, and merchants that accept Visa cards are mandated to be in production compliance with this process starting in October 2017, with an earlier migration date of April 2017 for the Hong Kong and New Zealand regions.

The VCR initiative seeks to simplify dispute processing by migrating from a litigation-based model to a liability assignment model. VCR leverages both transaction data and the Visa Resolve Online (VROL) platform to simplify the processing of disputed transactions by:

  • Confirming that disputes meet the necessary criteria for the selective dispute category
  • Proactively eliminating invalid disputes wherever possible
  • Promoting automated liability assignment
  • Reducing the resolution timeframe for disputes

Changes include:

  • Replacing the terminology of chargeback, reason codes, and representment with the more encompassing term “dispute processing.”
  • Replacing the existing 22 reason codes with four dispute categories, with processing defined in two flows:
    • Allocation – Used for fraud and authorization dispute categories. Visa determines an initial liability assignment in real-time. Acquirers and merchants obtain the ability to respond under certain conditions (for example, compelling evidence, invalid data, credit issued, and evidence of a manual imprint) by filing pre-arbitration.
    • Collaboration – Used for processing errors and consumer billing dispute categories. While most disputes fall under the category of allocation, a subset still require back and forth interaction between merchants, acquirers, and issuers. Through this process, resolution timeframes are reduced, and streamlined workflows simplify communication between parties.
  • Improving dispute resolution – Currently, disputes take approximately 46 days to resolve, with the more contentious issues taking more than 100 days. Using VCR, disputes are expected to be resolved within 31 days. The VCR initiative provides more efficient processing and reduces the need for multiple cycles of information exchange and documentation.
  • Improving communication – Most communication between the Issuer, Acquirer, and Visa occurs through the exchange of real-time XML messages, facilitated through the VROL platform. There are still several processes, such as an Exception filing in response to an Issuer liable fraud decision, that require manual entry into the VROL web portal.

These new processes should not be apparent to cardholders, who can still see certain types of errors on their statements that they are able to dispute. However, the process that the Issuer and the Acquirer follows to resolve these disputes requires changes, which are included in Pega Smart Dispute 7.21 for Issuers and Acquirers.

Issuer dispute creation

Smart Dispute has a redesigned dispute creation process that contains the elements and processes that are needed by an Issuer to initiate and resolve disputes through VCR, as well as the ability to manage the customer’s dispute in accordance with bank policies and regulatory requirements.

Whether the dispute is filed with a Customer Service Representative (CSR) or through a web self-service, the process is the same, as detailed in the following image:

Dispute process flow

  1. The transaction to be disputed is identified in the bank’s core transaction system.
  2. In customer-friendly language, the reason why the cardholder is disputing the transaction is specified.
  3. The VCR service SubmitTransactionInquiryOperation can be sent to Visa if necessary to retrieve transaction data directly from Visa, as well as to identify any associated transactions, such as credits, that might have been issued to offset the selected transaction.
  4. Questions that relate to the chosen dispute reason are presented to be answered. The questions are designed to gather required information from the customer that is used in determining the validity and outcome of the dispute.
  5. The system automatically checks business rules, such as the automatic write-off that could apply, and sets the appropriate consumer regulation flags and service-level agreements (SLAs).
  6. The system evaluates the transaction and associated dispute information to determine the appropriate recovery channel. Because Issuers can also subscribe to third party resolution services, the system uses the Issuer’s rules to determine if or when those services should be utilized.
  7. If applicable, additional business rules are evaluated.
  8. A case number is assigned and the dispute is routed to the back office for investigation
  9. The VCR service SubmitTransactionInquiryOperation is sent to request all of the transaction information that is needed for the dispute (if this has not been performed during the customer Q&A session). Based on Visa’s requirements, subsequent VCR messages are sent and the responses are processed in the background.
  10. A back office user retrieves the dispute to confirm that the necessary data is ready for dispute filing. (The dispute filing message can be configured to be sent in the background without operator intervention if all validations pass.) Based on the transaction detail and the customer interview, Smart Dispute defaults the dispute category and any other information that is required for the filing.
  11. Visa evaluates the transaction and question data in real time and determines whether the Issuer can proceed with filing the dispute.

The flows in Smart Dispute are configured to send request messages at appropriate points in the flow, as well as to process response messages and continue the flow accordingly. The app also includes a real-time interface so that customers only need to update rules with their Visa-supplied credentials.

Existing processes and terminology, such as reason codes and chargebacks, are unaffected in Smart Dispute for Master Card and American Express. They remain supported and are referred to as Visa legacy until the migration date in October 2017.

Allocation flow (Fraud/Authorization categories)

As previously described in this article, VCR utilizes a “liability-assignment model” by using the data in the transaction and the responses captured during the dispute creation process to assign liability for fraud and authorization related disputes, following the “Allocation” process.

  1. The fraud dispute filing includes the necessary data that is required for fraud reporting.
  2. Visa evaluates the transaction data and responses to the dispute questions that were gathered during dispute creation and assigns liability in real time.
  3. If liability is assigned to the Acquirer, the system executes accounting steps as appropriate to settle the dispute and to issue necessary credit.
    • Depending on business rules, the customer might have already received provisional credit. If the customer has not previously received provisional credit, the system initiates the necessary accounting steps for customer credit and entries to the Visa clearing account.
    • Smart Dispute assumes “VROL initiated financials,” which are controlled by the data element CreateDisputeFinancial when set to Y in SISubmitDisputeQuestionnaireRequest.
    • The Acquirer can accept the liability or not respond, both of which resolve the case.
    • The Acquirer can decline liability by filing a pre-arbitration case, which must be filed within 30 calendar days.
  4. If liability is assigned to the Issuer, the dispute is reviewed by the Issuer to determine the next action.
    1. Actions can include write-off, assigning the liability to the customer, or filing an exception request with Visa if there is compelling evidence that would affect the original decision, which is only available through VROL UI..

Similar to dispute creation, the flows are configured to send request messages in real time at the appropriate points in the flow, as well as to process the response messages and continue the flow accordingly.

Collaboration flow (Processing Error and Consumer Dispute categories):

If the dispute involves processing errors or consumer disputes such as “not as described,” then the system proceeds with the “Collaboration” flow, as detailed in the following image:

Dispute collaboration flow

  1. Visa evaluates the selected dispute flow, transaction data, and responses to the dispute questions that are gathered during dispute creation, and then determines if the information is valid to proceed with the dispute.
  2. If validated, Visa sends the information to the Acquirer for a response and issues a preliminary liability decision. Most valid collaboration disputes have initial liability assigned to the Acquirer, which generates an entry in the bank’s Visa clearing account.
    • Depending on business rules, the customer might have already received provisional credit. If the customer has not previously received provisional credit, the system initiates the necessary accounting steps for customer credit and entries in the Visa clearing account.
    • The system applies an SLA of 30 calendar days to wait for the Acquirer’s response, which is the timeframe in which the Acquirer must respond, as enforced by Visa.
  3. If the Acquirer accepts the dispute in full, or does not respond within the 30-calendar day SLA, the dispute is resolved in favor of the Issuer.
  4. If the Acquirer responds with a partial acceptance of the amount, or declines the dispute in full, the dispute is reviewed by the Issuer to determine the next action.
    1. These actions can include write-off, assigning the liability to the customer, or filing a pre-arbitration case with Visa if there is compelling evidence that would affect the original decision. Pre-arbitration must be filed within 30 calendar days.
    2. Depending on the Issuer action, the appropriate accounting steps are taken to either reverse a previous credit to the cardholder, write the dispute off as a loss, or adjust previous Visa clearing entries.
  5. Similar to dispute creation, the flows are configured to send the request messages in real time at the appropriate points in the flow, as well as to process the response messages and continue the flow accordingly.

Web services

As previously described in this article, Smart Dispute contains all of the necessary services that are required to interact directly with Visa for dispute processing. The data type Pega VCR Services lists the SOAP Services and the data transform rules that are used for the request and response. Also included are the data transform rules that can be used in simulation mode for testing and training while not connected to Visa.

The services that are required for Issuer VCR processing, and the flows in which they are initiated as of this release, are listed in the following table.

Nov-2016 IES/ wsdl Services

Action

SD Issuer Flow

CloseRFCOperation

Internally called in flows

VCR_RFC_Fulfillment_Flow

CloseTransactionOperation

Internally called in flows

AcceptAndCloseDispute

FraudReportDetailsOperation

Local Action

ViewFraudReport - Flow action
EditFraudReport - Flow action called by PegaCard-Sd-Dispute-Visa-International-US-Wki pyDefault case type

GetBatchQueueOperation

Internally called in flows

Called from Agents

GetCollaborationDetailsOperation

Internally called in flows

HandleVCRGoodFaithResponse

GetFulfillmentOperation

Internally called in flows

VCR_RFC_Fulfillment_Flow

GetImageOperation

Internally called in flows

VCR_RFC_Fulfillment_Flow

GetRFCNonFulfillmentOperation

Internally called in flows

VCR_RFC_Fulfillment_Flow

HyperSearchOperation

Internally called in flows

VCR_RFC_Fulfillment_Flow
GetArbitrationContactMessages
PreComplianceInboundResponse
ReviewArbitrationDetails

IgnoreRejectOperation

Option-Screen

MarkBatchQueueItemAsReadOperation

Internally called in flows

Called from Agents

SubmitCollaborationOperation

Local Action

InitiateVCRCollaborationFlow

SubmitExceptionOperation

Local Action

SubmitExceptionFile - Activity called from flows

SubmitFraudOperation

Local Action

SubmitFraudReport - flow action

SubmitRFCOperation

Local Action

CreateRFC

UpdateCaseResolutionStatusOperation

Internally called in flows

UploadImageOperation

Internally called in flows

Called from UploadImage activity. Called from multiple activities to upload documents to VCR (Eg: SubmitDisputeFilingRequest Data transform)

CreateCaseFromTransactionOperation

Internally called in flows

CreateRFC
CreateVisaCase

GetAssociatedTransactionListOperation

Internally called in flows

AssociatedTranFlow
InitiatePreCompForIssuer
PreArbitrationInboundResponse
VCRPreArbitrationFlow

GetTransDetailsOperation

Internally called in flows

TranInquiryFlow

GetTransInquiryResultsOperation

Internally called in flows

TranInquiryFlow

SubmitTransactionInquiryOperation

Internally called in flows

TranInquiryFlow

AcceptDisputeOperation

Internally called in flows

AcceptAndCloseDispute

AssociatedTranSelectionOperation

Internally called in flows

AssociatedTranFlow

ChangeDisputeStatusOperation

Internally called in flows

DisputeRecallFlow

CreateDisputePreArbOperation

Option-Screen

VCRPreArbitrationFlow

CreateDisputePreArbResponseOperation

Option-Screen

PreArbitrationInboundResponse

CreateDisputePreCompOperation

Local Action

InitiatePreCompForIssuer

CreateDisputePreCompResponseOperation

Local Action

PreComplianceInboundResponse

GetContactMessageDetailsOperation

Internally called in flows

RespondToArbitrationContactMessage

GetDisputeFilingDetailsOperation

Internally called in flows

ArbitrationFlow
ComplianceFlow
ProcessAssociationDecision
ProcessComplRespForAcq
ReviewArbitrationDetails

GetDisputePreArbDetailsOperation

Internally called in flows

PreArbitrationInboundResponse

GetDisputePreArbResponseDetailsOperation

Internally called in flows

PreArbitrationFlow
PreArbResponseProcessing

GetDisputePreCompDetailsOperation

Internally called in flows

PreComplianceInboundResponse

GetDisputePreCompResponseDetailsOperation

Internally called in flows

PreComplianceInboundResponse
ProcessPreCompRespByAcq

GetDisputeResponseDetailsOperation

Internally called in flows

SubmitAcquirerResponse

InitiateDisputeFromTransactionOrCaseOperation

Option-Screen

DisputeCreationFlow

InitiatePreCompFromTransactionOrCaseOperation

Local Action

InitiatePreCompForIssuer

SubmitContactMessageResponseOperation

Option-Screen

ArbitrationFlow
ComplianceFlow
ArbOrCompWithdrawal
VCRAppealArbitrationRulingFlow
VCRAppealRulingFlow

SubmitDisputeFilingOperation

Option-Screen

ArbitrationFlow
ComplianceFlow
ArbOrCompWithdrawal
VCRAppealArbitrationRulingFlow
VCRAppealRulingFlow

SubmitDisputeQuestionnaireOperation

Option-Screen

DisputeCreationFlow

The services listed in the following table are included with Smart Dispute for Acquirers 7.2.1. Note that some messages are common to both the Issuer and the Acquirer.

Nov-2016 IES/ wsdl Services

Action

SD Acquirer Flow

CloseTransactionOperation

Internally called in flows

AcceptAndCloseDispute

GetBatchQueueOperation

Internally called in flows

Called from Agents

GetImageOperation

Internally called in flows

VCR_RFC_Fulfillment_Flow

GetRFCAdviceOperation

Internally called in flows

VCR_Process_RFC_Flow

HyperSearchOperation

Internally called in flows

VCR_RFC_Fulfillment_Flow
GetArbitrationContactMessages
PreComplianceInboundResponse
ReviewArbitrationDetails

MarkBatchQueueItemAsReadOperation

Internally called in flows

Called from Agents

SubmitCollaborationOperation

Local Action

InitiateVCRCollaborationFlow

SubmitFulfillmentOperation

Option-Screen

VCR_Process_RFC_Flow

SubmitRFCNonFulfillmentOperation

Option-Screen

VCR_Process_RFC_Flow

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.