When getting authorization date from Visa QFD has trouble determine timezone which could result in incorrectly determining the authorization date.  The system should only fail the fraud reporting validation when the local transaction date is greater than 2 days from fraud reporting date.  

1. When the transaction date is being compared to the fraud reporting date the fraud reporting date should be buffered by 1 day for any potential timezone issues.
2. When the system is evaluating which transaction date should be used it should leverage the earlier of the LocalTransactionDateTime between the auth and clearing data returned from Visa.

Visa's transaction date information has been inconsistent in production and sometimes the auth record is better to leverage for the authorized after the fraud reporting.  Then other times the clearing transaction details is better to leverage.  The system will now check both and use the earlier of the two dates.

As a system, when Lob fails due to an outage QFD should retry every hour up to three times. 

1. When a LOB letter fails the system will retry every 60 mins for 3 times.

Increases retry timing for LOB from 15 mins between attempts to 60 mins between attempts.  In the event LOB goes down for less than 3 hours the retry logic will now pick them up and process them prior to routing to a failure work queue.

When visa returns a error to pass ChipOnCard, QFD should pass the indicator based on the value defined in client information.

1. When a visa chargeback fails for missing ChipOnCard property, QFD passes the ChipOnCard based on client info rule.
   1. When the client issues chip cards the ChipOnCard value is passed as "Y"
   2. When the cleint does not issue chip cards the ChipOnCard value is passed as "N".

Visa conditionally requests to pass chip on card; when it is not passed and expected visa will throw a error asking for it.  When this happens QFD will retry the request message with ChipOnCard passed. 

When a transaction is being enriched in the Mastercard workflow today if the service returns that a claim id already exists we take that claim and map it back to the dispute.  QFD currently does not also check that the mastercom claim id is not already associated with another dispute and it can cause downstream issues if the case is allowed to continue.  When this happens enrichment should fail out.

1. When QFD calls to create a case in Mastercom and a claim id exists the system should check if the Mastercom claim id is already associated with another dispute.
   1. When there is already a dispute existing, enrichment should fail; and it should write the duplicate dispute id to the dispute level audit.
   2. When there is not already another claim id tied to a existing dispute QFD will take the claim id returned and associate with the disputed transaction being enriched.
2. When the Mastercom service call to create a claim fails, the error should be displayed on the failed enrichment assignment.

QFD has logic in MC error handling where if the claim already exists, it will map the claim from the failure response from Mastercard.  Additional logic was added here to check if that mastercom claim id already exists in the system.  If it does the service will fail.

As a system, when I am configured to delay accounting until after recovery, if a dispute is waiting in a tollgate or approval and the regulatory resolution deadline is reached, I should resolve the claim as paid and generate the necessary correspondence and accounting.

1. When configured to delay accounting until after recovery, and a dispute is waiting in a tollgate or approvals, when the regulation deadline is reached, the claim is resolved as paid, a resolution letter is generated, and final credit accounting is performed.
2. When a dispute is waiting in the resolution tollgate, it resumes 1 calendar day before the regulatory resolution deadline.

Resolved an issue where final credits were performed late when a client is configured to execute accounting post-recovery and a recovered dispute is waiting in a tollgate, or for an approval.  This change ensures that these disputes will resume to resolution before the regulatory resolution deadline.

When someone back dates a claim which triggers it to be greater than 7 days old from the reg date, final reg will never be processed.  The report def to pick up these cases looks at 7 days.

1. When a claim is backed dated past the reg deadline regardless of how old, the reg fires as expected when the agent runs.
   1. Back date a claim so that the reg expired 100 days ago, case is paid.
   2. Back date a claim so that the reg expired 30 days ago, case is paid.
   3. Back date a claim so that the reg expired 5 days ago, case is paid.
   4. Back date a claim so that the reg expired 1 days ago, case is paid.
2. (dev only) expose the Is Contact  Date Overridden 
3. When a Contact Date has been overridden and the claim is backdated past the reg deadline, regardless of how old, the reg fires as expected.

Resolved an issue where when a user back dated a claim to more than 7 days from Regulatory resolution date, final regulation system processing was not triggered. This fix ensures that when a claim is backed dated past the regulatory deadline the system processes as expected.