Working with Regulation E

Regulation E, the United States regulation implementing the Electronic Fund Transfer Act, provides a framework for protecting customers who use electronic methods to transfer money, as well as guidelines for electronic debit card issuers throughout the dispute investigation process. Regulation E allows up to 45 calendar days (90 days in certain cases) to resolve these disputes, but during that time you must issue a provisional credit for the disputed amount. The provisional credit must be provided within 10 business days after the customer made first contact. If a dispute is not resolved within the required 45-day (90-day in certain cases) time frame, Marqeta makes the provisional credit permanent without confirmation.

​

Provisional credit overview

When you create a Regulation E dispute case using the /cases endpoint:

• Use the cardholder_contact_date field to add the date of first cardholder contact. When you create the case, the 45-day clock begins. Marqeta provides this milestone due date in the response payload.
• Grant the customer provisional credit using the GRANT_PROVISIONAL_CREDIT action in the actions endpoint, which transfers funds from the program account to the cardholder account. This endpoint can only be called before card network submission.
• If provisional credit is not provided at time of submission to the card network, Marqeta sends you an error response and moves the case to an OPEN_WITH_ACTION_REQUIRED state.
• If provisional credit has been provided and other card network requirements are satisfied, you can submit to the card network using the CHARGEBACK_SUBMIT dispute transition action.

​

Managing provisional credit

The following sections describe how to manage provisional credit using the cases endpoint if your program is enabled for Regulation E.

​

Creating the dispute case

If the dispute reason has a supported dispute reason code, a chargeback is created when you create the dispute case. The chargeback token is stored in dispute_details and the regulation_type field is set to REG_E. A PC_PENDING milestone is created with a due date calculated as follows for provisioning credit: cardholder_contact_date + days to act

​

Monitoring elapsed time

For Regulation E cases, it is your responsibility to provide a provisional credit within 10 business days of the cardholder_contact_date. The Disputes dashboard provides a warning if the 10-business-day timeline for providing provisional credit is expiring. To look up the expiration date for one-off cases, use the GET /cases/{token}/milestones endpoint and look for the next_milestone_due_date when the milestone is set to PENDING_PC_GRANTED for the PROVISIONAL_CREDIT subcategory. If provisional was not provided within the regulation time frame, the system will still allow you to grant provisional credit.

​

Granting provisional credit

To grant provisional credit, use the POST /cases/{token}/actions endpoint with GRANT_PROVISIONAL_CREDIT as the action_type. Provisional credit must be granted before the case enters the CHARGEBACK_INITIATED state. The credit can be granted while the dispute case states in any of the following states: OPEN, OPEN_WITH_ACTION_REQUIRED, or READY. This triggers the ProvisionalCreditGranted event and sets the provisional_credit_granted field in dispute_details to true. This triggers the authorization.clearing.chargeback.provisional.credit webhook.

​

Submitting a dispute to the card network

Before you submit a dispute case to the card network, you must grant provisional credit. To initiate a dispute by submitting it to the card network, create a dispute case transition using the POST /cases/{token}/transitions endpoint with a CHARGEBACK_SUBMIT action to transition the case to CHARGEBACK_INITIATED. If the provisional credit has not been granted, the case is moved to OPEN_WITH_ACTION_REQUIRED. Submitting a dispute case to the card network triggers the authorization.clearing.chargeback and the chargebacktransition.regulation.initiated webhooks.

​

Handling card network rejection

There are three possibilities if the chargeback is rejected by the card network:

• Cardholder should keep the provisional credit – You determine that the cardholder should keep the provisional credit. In this scenario you would CLOSE the case with writeoff program.
• Cardholder should not keep the provisional credit – You determine that the cardholder should not keep the provisional credit. In this scenario, close the dispute case with case lost. If the case has been opened for less than 45 calendar days, this triggers the Post-network submission – case lost pre 45 days use case.
• Cardholder is at fault, but 45 calendar days have passed – You determine that the cardholder is at fault, but the case has been opened for more than 45 calendar days. In this scenario, you would CLOSE the case with writeoff program, given that the credit has already been made permanent.

If a case is rejected by the card network, Marqeta provides you with a reject reason, sends a regulation.network.rejected webhook, and moves the case to the OPEN_WITH_ACTION_REQUIRED state. You are responsible for evaluating the card network rejection and determining if the dispute should be resubmitted. If you choose to resubmit, Marqeta continues to persist the provisional credit against the customer account. You are responsible for notifying the cardholder of the final decision. For a card network rejection use case, see Post-network submission – card network rejection.

​

Pre-network submission cases

In these two cases you may want to withdraw and close before submitting to the card network:

• You create a dispute case and then discover that the disputed transaction has an associated transaction for a refund or credit already in the system.
• After investigating a dispute case rejected by the card network, you determine that the case is lost and want to close the case.

For each of these use cases, see Pre-network submission – withdraw and close and Pre-network submission – close with case lost pre 45 days.

​

Case lost

If the case is lost, transition the dispute to CLOSED with case lost reason code. This puts the case in the PENDING_CLOSED state, which requires you to:

• Notify the cardholder at least five days in advance that the credit will be reversed.
• Trigger an event with the date of notification.
• Wait five days for the funds to be reverted and the case to be closed by the system.
• Indicate to Marqeta that you notified the cardholder and when you notified them. Marqeta will reverse the credit eight days from when the case was lost.

The following sections provide details for a case lost scenario. For case lost use cases, see Post-network submission – case lost pre 45 days and Post-network submission – case lost post 45 days.

​

Managing elapsed time

If the current date is more than 45 days after the cardholder_contact_date, the provisional credit is made permanent. For details, see Permanent credit. If the current date is less than 45 days after the cardholder_contact_date, and the case is lost, the case_lost state is recorded and a Case Lost CC Pending event is generated. To determine the due date for the PC_PERM, use the GET /cases/{case-token}/milestones endpoint and refer to the next_milestone_due_date when the current milestone is set to PC_GRANTED. When the CaseLostNotifyCardholder event is triggered, a regulation.case.lost.action.required webhook is sent with the expectation that you will notify the cardholder of the reversal of funds at least five days in advance. The milestone is updated to PENDING_PC_REVERSAL with the next milestone_due_date set to eight days from the time the case was moved to the PENDING_CLOSED state. A new CASE_LOST_PENDING_COMMS milestone is also created with a next_milestone_due_date set to three days from the time the case was moved to PENDING_CLOSED.

​

Notifying the cardholder

Once you notify the cardholder, you must trigger a CaseLostNotificationSent event and specify a date when you notified the cardholder through the event_date field. This updates the next_milestone_due_date for the PENDING_PC_REVERSAL milestone. If you do not send the CaseLostNotificationSent event, a CaseLostNotifyCardHolderExpired event will move the milestone from CASE_LOST_PENDING_COMMS to CASE_LOST_COMMS_EXPIRED. In this scenario, you will no longer be able to change the next_milestone_due_date for the PENDING_PC_REVERSAL. Failing to send the CaseLostNotificationSent event will result in the cardholder’s account being debited without any prior notice. It might also result in the cardholder’s account being debited on a date different than what was previously communicated to the cardholder. To see when the reversal of credit is due, use the GET /cases/{case-token}/milestones endpoint and refer to the next_milestone_due_date for the PENDING_PC_REVERSAL milestone.

​

Case won

If more than 45 days have passed from the cardholder_contact_date, the provisional credit is made permanent. For details on permanent credit, see Granting permanent credit. If case_won_date is less than 45 days after the cardholder contact date, the case_won state is recorded and a provisional credit perm event is generated. It is your responsibility to inform Marqeta of the date of the provisional credit perm confirmation and that the Case Won confirmation were sent to the cardholder. For a case won use case, see Post-network submission – case won.

​

Granting permanent credit

If no case decision is recorded within 45 days of the cardholder contact date, a webhook is generated indicating that provisional credit to the cardholder should be made permanent. It is your responsibility to inform Marqeta of the date that the provisional credit perm and that the Case Won or Case Lost confirmation was sent to the cardholder. The case continues investigation with the card network, but any subsequent updates should not impact the cardholder. All ledger-impacting activities after this event should impact the program funding source or Marqeta funding.

​

Program funding source impact

Provisional credit is taken from the program funding source. When a case is lost or has progressed beyond the 45-day time limit, funds are recouped from the program funding source. After the provisional credit is issued, all ledger impact is on program funding source and the card network account during the dispute lifecycle.

​

Reason Codes Supported for Reg E Configuration

The following dispute reason codes are supported by Marqeta and are most commonly associated with Reg E.

• EMV_LIABILITY_SHIFT_COUNTERFEIT_FRAUD (Visa only)
• EMV_LIABILITY_SHIFT_NON_COUNTERFEIT_FRAUD (Visa only)
• NOT_AUTHORIZED_CARD_PRESENT
• NOT_AUTHORIZED_CARD_ABSENT
• LATE_PRESENTMENT
• INCORRECT_TRANSACTION_CODE
• INCORRECT_CURRENCY
• INCORRECT_ACCOUNT_NUMBER (Visa only)
• INCORRECT_TRANSACTION_AMOUNT (Visa only)
• CANCELLED_RECURRING_TRANSACTION
• NON_RECEIPT_OF_CASH_OR_LOAD_TRANSACTION_VALUE_AT_ATM
• WARNING_BULLETIN_FILE
• INCORRECT_TRANSACTION_AMOUNT_OR_ACCOUNT_NUMBER
• POINT_OF_INTERACTION_ERRORS
• FRAUD_TRANSACTION
• QUESTIONABLE_MERCHANT_ACTIVITY
• TRANSACTION_NOT_RECOGNIZED
• CHIP_LIABILITY_SHIFT
• CHIP_PIN_LIABILITY_SHIFT_LOST_STOLEN
• CHIP_READ_POS_LATE_PRESENTMENT
• DUPLICATE_PROCESSING_OR_PAID_BY_OTHER_MEANS

​

Use cases

The following are common scenarios when managing Regulation E dispute cases:

• Pre-network submission – withdraw and close
• Pre-network submission – close with case lost pre 45 days
• Post-network submission – card network rejection
• Post-network submission – case lost pre 45 days
• Post-network submission – case lost post 45 days
• Post-network submission – case won

The following sections describe the steps required and responses for each of the use cases. Boldface steps are those that are your responsibility to perform.

​

Pre-network submission – withdraw and close

In this scenario, a customer creates a dispute case and the disputed transaction has an associated transaction for a refund or credit already in the system. If the refund or credit is for the full amount, you should not grant provisional credit, but instead close the case with WITHDRAW_AND_CLOSE.

​

Pre-network submission – close with case lost pre 45 days

In this scenario, you submit a case to the card network, but the card network rejects the submission. After further investigation, you determine that the case is lost and close the case. The following steps show the sequence in this scenario:

​

Post-network submission – card network rejection

In this scenario, you submit a case to the card network, but the card network rejects the submission. After further investigation, you determine that there is no chargeback, but you would like to return the money to the cardholder. The following shows the sequence of steps:

​

Post-network submission – case lost pre 45 days

This scenario outlines for going to REPRESENTMENT, but this can also apply if the case goes to PRE_ARBITRATION or ARBITRATION.

​

Post-network submission – case lost post 45 days

In this scenario, the case is lost after the 45 days have passed. In this scenario, the dispute case goes to REPRESENTMENT, but this can also apply if the dispute case goes to PRE_ARBITRATION or ARBITRATION.

​

Post-network submission – case won

In this scenario, a post-network submission is set to case won.