A DSS FNSCounter is created such that the FNS counter limit can be updated as 35 by clients effective November 7, 2023. All the referencing rules where the FNS limit is hardcoded as 15 are replaced with the value from the DSS FNSCounter.

• Issuers are allowed to submit a maximum of 35 (FNSCounter limit set as 35) Fraud chargebacks on the same account number after which the Fraud reason codes (4837, 4870 and 4871) will not be displayed in the Choose a Reason Code screen.
• Disputes that have crossed Choose a Reason Code stage and if the chargebacks are yet to be submitted to MasterCom, then the dispute validation outcome associated to FNS counter is displayed as ‘Fail’ if the chargeback count exceeds FNS counter limit.

1. Create a MCom fraud dispute case where FNSCounter for the account number is 35
2. Submit Qualify fraud dispute screen
3. In the Answer ancillary question screen, verify fraud reason codes are not displayed in the reason code dropdown
4. Similarly, repeat above steps with account number having FNSCounter less than 35.
5. In the Answer ancillary question screen, user should now be able to see the fraud related reason codes in the reason code dropdown and the dispute validation outcome related to FNS counter is displayed as “Pass”

In Smart Dispute for Issuers (SDI) application, when an inbound representment is received with document indicator as ‘true’, the dispute is routed to Waiting for docs assignment with an SLA of 8 days.

Acquirers can submit the supporting documents within 8 days and if the inbound document is not received after 8 days, application routes the dispute to Review second presentment assignment where the issue can either ‘Accept’ or ‘Initiate Pre-arbitration’.

As per MasterCom guidelines, if the Acquirer submits the supporting document after 8 days and before the Issuer initiates a Pre-arbitration, then the Issuer must review the inbound documents before raising a Pre-arbitration.

1. Create a MCOM dispute
2. Submit the Qualify dispute screen and proceed to answer ancillary questions and submit the chargeback
3. Verify dispute is at Awaiting acquirer response.
4. If an inbound representment is received with documentIndicator as ‘true’, then verify the dispute is routed to Waiting for docs assignment
5. Wait for SLA to expire (8 days) and the case proceeds to the Review Second Presentment screen
6. Select ‘InitiatePre-Arbitration’ and verify application routes the dispute to the Review Second Presentment screen if the supporting documents are attached by the Acquirer.

The FiledagainstICA field is not auto populated in the Initiate Pre-Compliance screen if the Issuer initiates Pre-Compliance before chargeback submission.

1. Create a MCOM case with any reason code and proceed till Answer ancillary questionnaire screen.
2. In the Answer ancillary questionnaire screen, select Initiate Pre-compliance from other actions.
3. Verify the FiledagainstICA field is pre-populated in the Pre-compliance questionnaire screen.

1. Create a MCOM acquirer case in simulation
2. Select reason code as ‘4853’ and condition code as ‘-‘
3. Verify case lands on to the Review Inbound Chargeback screen.
4. Verify the reason code and condition code are populated in the dropdowns.

As an Acquirer, when I represent an inbound 4853 chargeback with representment reason as Credit Previously Issued or General Second Presentment, application is throwing the below error:

1. Create a MCOM Acquirer dispute with inbound chargeback reason code as 4853
2. Proceed till representment and select representment reason as Credit Previously Issued and submit the representment.
3. Verify representment is successfully submitted to MCOM

1. Create a MCOM Fraud dispute.
2. In the Qualify fraud dispute screen, select Fraud type as Card not present fraud and answer the question Are you in possession of your card as ‘Yes’.
3. Submit Fraud 4837 chargeback to MCOM and verify the EBDR document displays the question The cardholder was in possession and control of the card issued to the account at the time of the transaction or the card used was counterfeit:as ‘Yes’.
4. Continue till Pre-arbitration and submit the Pre-arbitration without changing the dispute reason.
5. Observe that EBDR document generated at Pre-arbitration stage displays the question The cardholder was in possession and control of the card issued to the account at the time of the transaction or the card used was counterfeit:as ‘Yes’.

In December 2022 Maintenance release, a fix was provided to address a gap in handling technical exception followed by a business exception. The fix is not working for Visa Debit disputes.

In a Visa Debit dispute, when a technical exception is encountered while invoking Visa RTSI APIs, the case is routed to the ProblemFlowWorkBasket. Upon retry when a business exception is encountered in the API, system creates a Display Previous Assignment instead of automatically routing the dispute to a valid previous assignment.

For Visa Debit classes, rules from PegaCard-Sd- are ranked top during resolution due to the inheritance structure. Hence, the placeholder when rule PegaCard-Sd-.WhenProblemFlow that always evaluates to false was executed during run time for Visa Debit disputes.

1. Create a VCR Debit claim
2. Perform Qualify dispute by selecting any dispute reason
3. Ensure that Transaction Inquiry fails due to a technical exception
4. Observe that dispute lands into ProblemFlowWorkBasket
5. Open ProblemFlowWorkBasket assignment and click Submit to retry the API
6. Ensure that Transaction Inquiry fails due to a business exception
7. Observe that case is rerouted to Qualify dispute assignment.

In Smart Dispute for Issuers, it is observed that certain disputes are created without any Claim case.

These disputes are not in an actionable state since the audit and the state of pxFlow indicate that,

• The disputes are not created through proper channels because DisputeMainFlow is not found.
• The disputes are directly created by the Batch Queue processing agents, especially pre-arbitration and pre-compliance processing agents.

During batch queue processing, the agents use the activity VCR_BatchQueueProcessing which is common for Smart Dispute for Issuers and Smart Dispute for Acquirers.

The activity VCR_BatchQueueProcessing iterates on all queue records and looks for a matching case.

When a matching case is found, ResumeVCRFlow utility is executed by passing current parameter page. ResumeVCRFlow initializes FlowName and FlowActionName parameters to resume the existing case.

In Smart Dispute for Issuers, when no cases are found, system is expected to skip processing the queue item. However, since the FlowName parameter initialized inside ResumeVCRFlow was not reset after processing a matching case, for the next queue item, if no case is found, InvokeFlow activity is executed resulting in creation of orphan cases thereafter.

1. As an Issuer, read items from the Visa batch queue - AWAITING_ACTION_BQ_PRE_FILING, such that some queue items have no matching disputes in Smart Dispute. This can be simulated by directly creating and processing claims in VROL.
2. After the batch queue processing agents have completed execution, ensure that for queue items with no matching cases, no orphan cases are created.

1. Create a VCR fraud dispute case
2. Submit Qualify fraud dispute questionnaire and proceed until Arbitration.
3. At this stage, Issuer can decline the inbound Arbitration and proceed for appeal.
4. At this stage, Issuer should be able to see 2 assignments ‘Awaiting final decision by Visa’ and ‘Wait for contact message’
5. The ‘Wait for contact message’ assignment should be removed only after the association ruling is received

1. In SDA application, select Initiate Pre compliance
2. In Initiate Pre-compliance screen, verify dispute amount is displayed.

• In SetParamsForUpdateClaimDetails data transform, added steps 4 and 5 where "Param.IsClaimUpdated" and "Param.pzInsKey" is set to null.
• In SetAndValidatePropsForDispCategs activity, updated 6th step to AccountTransaction.PostedAmount property.

1. Create a claim case by disputing multiple transactions (MCOM/VCR/AMEX)
2. Select 'Update Claim Details' from actions menu at claim
3. Update dispute amount for any one of the disputes and submit
4. Verify the dispute amount is updated properly in overview tab for the selected dispute.

In the review harness, the assignments are loaded from pxFlow page. Although the disputes are resolved and the assignments are deleted, the flows were not ended and so they still had references to the assignment. This is due to a misconfiguration in the PostCustomerLiableAction activity. The activity uses a wrong step page while invoking the OOTB activity pxDeleteAssignment resulting in pxFlow changes not being propagated to the dispute work objects.

As a fix, the step page is correctly passed and pxFlow changes are propagated and persisted in all the customer liable disputes.

1. Create a new Claim with multiple transactions
2. Qualify all the disputes
3. In the Claim, select multiple disputes and click Actions à Customer Liable
4. Select the disputes and click Submit
5. Observe that the disputes are resolved as Resolved-CustomerLiable
6. Open any resolved dispute and observed that there are no open assignments

The visibility condition is defined such that if the property NetworkDesc exists and has a value, the field is displayed as Read-Only.

However, when navigating from one page to another, the system renders the contents in the grid again re-evaluating the read-only conditions. The field becomes read-only since a value is selected in the dropdown and available in the clipboard.

1. Login as a CSR or Back Office user
2. Click Create à Claim
3. Enter an account number and click Search
4. In the transaction results, identify a Reg-II eligible transaction and select a network in the Network ID dropdown
5. Navigate to a different page and return to the same page again using the paginators above the results table
6. Observe that, for the Reg II transaction, the value selected in Network ID is still visible and the drop down is still editable.

• Updated visibility condition of layouts in section ‘DisplayFraudQuestionnaireForTxn’ to not display questionnaire when ‘Skip qualify questionnaire’ option is selected
• Also, modified section ‘CSRInterviewTab’ to add spacing in Interview tab and updated section ‘QualifyFraudDisputes’ to remove bin/delete icon from transaction grids.

1. Login to Smart Dispute for Issuers application as a CSR operator
2. Create Claim by selecting 5 debit transactions with combination of Reg-II and non Reg-II transactions and proceed till the Qualify fraud screen
3. In the Qualify fraud screen, grids are displayed for Reg-II and non Reg-II transactions. Verify that these grids should not have bin/delete icon for rows.
4. When the operator selects the Skip qualify questionnaire option, then verify questionnaire is not displayed
5. Submit the claim case
6. Verify questionnaire is not overlapped in Interview tab of the disputes and also observe dispute amount is displayed appropriately in Overview tab of the disputes.

The table layouts are replaced with embedded sections in DisplayQuestionnaireForTxn and CrossNetwork section displays the table for Reg II transactions.

1. Login as a CSR operator
2. Click Create à Claim
3. Enter an account number and click Search.
4. In the transaction results, select more than one transaction and create claim
5. In Qualify dispute screen, expand any row, answer the questionnaire, and click on save.
6. Observe that, there are no alignment issues in the table columns

1. Login as a CSR operator
2. Create a claim with multiple transactions
3. Proceed till Qualify dispute questionnaire and answer the questionnaire for first transaction. Click on save.
4. Click on Copy questionnaire
5. Observe that other transactions are copied with the same questionnaire details as answered in the first transaction questionnaire

1. Login as a Back office user
2. Click CreateClaim.
3. Enter an account number and click Search
4. In the transaction results, select more than one transaction and create claim
5. On claim level review screen, observe that, the alignment between the list of assignments is proper.

1. Create a VCR/MCOM dispute case
2. Select 5 transactions, check fraud checkbox, and create HND claim
3. Submit display HND cases assignment
4. On Display duplicate cases screen, click on Resolve as duplicate case button
5. Observe that application is not throwing any error.

In Smart Dispute for Issuers application, when a disputes manger opens Reg E - All Open Cases by Reg E Final Date report, the report is showing more than one result for same date. Similar issue is observed in Reg Z report as well.

In the report definition OpenCasesbyRegEFinalDateALL, the day portion of function is applied on the column source “RegEFinalDate”.

In the report definition OpenCasesbyRegZFinalDateALL, the day portion of function is applied on the column source RegZFinalityDate.

1. Login to Case Manger portal
2. Click on reports
3. Open the All Open Cases by Reg E Final Date report
4. Observe there are no duplicate rows for same date.

To handle the above scenario, the below changes have been implemented:

Flow: PegaCard-Sd-Dispute- ReviewAuthInitiatedDispute:

Added logic to resubmit the posted case to Ethoca by calling the subprocess CallThirdPartyResolutionNetwork (pre-condition is to check if transaction is posted)

Data transform :PegaCard-Sd-Dispute-RemovePendingAuthEhocadata:

1. Enable Ethoca as Third Party Resolution Network in Smart Dispute configurations
2. Create MCOM fraud/dispute case on a pending transaction
3. Submit the Qualify dispute questionnaire and proceed until Pending Authorizationdisclosure submission.
4. Observe application submits the pending transaction details to Ethoca
5. Application waits for Batch ID generation and after the Batch ID is generated, application checks if Alert ID is generated by either through manual polling or through call back service
6. After the Alert ID is generated, application checks if Merchant outcome is available by either through manual polling or through call back service
7. If the pending transaction is posted, observe that the transaction is submitted to Ethoca again with updated details and steps 4, 5 and 6 are triggered again.