The following properties should be exposed:

DatesChargebackRightsExpire

NACHAReturnDeadline

FromPendingPyID

1. The following properties should be exposed:
   1. DatesChargebackRightsExpire
   2. NACHAReturnDeadline
   3. FromPendingPyID
2. The Overview Tab table displays values for the following columns:
   1. Nacha Recovery date
   2. Dates Chargeback Rights Expire

Resolved an issue where properties within the Overview tab were not exposed to the user resulting in a blank field on the Overview tab. This fix ensures that the Date Chargeback Rights Expire and the NACHA Return Deadline Date are displayed to users when added to the Overview tab table.

Currently, if we run ARIA, it always displays to the end user.  Some clients use the investigation assignment, and adding this to the UI when we are only using it to collect data is problematic.  We need to be able to optionally hide ARIA details while collecting data only.

1. When ARIA is collecting data only (does not automate any decisions) there should be a configurable option to hide the ARIA results from the end user.
2. When the configuration to hide ARIA results is enabled,  non-Quavo users will not see ARIA results on the investigation tab.
3. Quavo users should always see ARIA results on the investigation tab, if ARIA successfully returned results.
4. When the configuration to hide ARIA results is not enabled, or is null, all users will see ARIA results on the investigation tab.
5. By default, when ARIA is initially set up, the configuration should be to show ARIA results.

Added a configuration point to hide ARIA results when user action is not required.

This is the story for pega side of things

1. When service data is not available for a given type of data (ex: transaction data, customer data, decline history data) that detail should be passed to the ARIA service  (note: Any subsequent evaluations that are completed based on that data will be skipped by ARIA.)
2. If a factor has a failure reason associated to it, that data should be persisted in a way that can be reported on via BIX, and that is displayable to a user.

Added a flag to ARIA data service call to determine if data was successfully retrieved from the service.

Summary: Currently it is possible that the claim level logic and dispute level ARIA logic get out of sync with each other. Normally, the claim will move disputes that are pending ARIA result mapping, however sometimes the claim moves before the disputes make it to that part of the flow. Because of this, a change was added to skip past the pend if the dispute already had an ARIA decision. The problem with this logic is that it then routes to process automation or ask a user for review, and if the claim already moved on, it will not be able to move the dispute out of review (also there will not be an assignment for a user to review). This causes the dispute to be stuck and unworkable. Before, the pend review option was only available if ARIA automation was enabled. Currently, that logic gets skipped if we have an ARIA decision, which causes this issue to happen.

Environment Specifics:

• Url: Greendot Quavo Cloud
• Claim Info: Any claim where an ARIA decision was generated before the dispute made it to the ARIADecisioning flow.

Steps to Reproduce:

1. Trigger ARIA from the claim level, but don't have the dispute in the ARIADecisioning flow yet. Make sure that ARIA automation is turned off.
2. Notice that after the claim level assignment moves on that the dispute level assignment will become orphaned.

Expected Result: Disputes should never route to review if automation is not enabled.

Actual Result: Disputes are routing to review when automation is not enabled.

Additional Info such as screenshots, error logs, etc.:

1. When ARIA decisions a dispute, if client info does not automate any decisions based on ARIA results, the dispute should never route to review.

Corrected an issue that was causing disputes to become out of sync with claim flows when ARIA decisions were automated.

Summary: When ARIA makes a Deny decision (or the user accepts her deny decision), QFD is sending the NoErrorOccurred letter.  If the client is configured to use Deny Justifications, those are going out blank.

Environment Specifics:

• Url: https://gdc-app.quantumdisputes.com/prweb/PRAuth/QVOSSO
• Credentials: SSO
• Claim Info: 230419000325C

Steps to Reproduce:

1. File a Card Secure fraud claim on a chip-read transaction
2. Let ARIA deny the claim
3. Review letter

Expected Result: The "No Error - ARIA Denial" letter is sent

Actual Result: Letter is sent with empty Deny Justification

Additional Info such as screenshots, error logs, etc.:

1. When ARIA automatically denies a dispute, the "No Error - ARIA Denial" letter is sent.
2. When a user accepts an ARIA decision resulting in a dispute denial, the "No Error - ARIA Denial" letter is sent.
3. The "No Error - ARIA Denial" letter should never be shown in the communications hub.

See attached letter example.  The letter should be a clone of the existing letter with a few verbiage differences, and have no denial justifications available.

Created a new No Error Occurred letter to be used when cases are denied by ARIA.