About Regulation E

Regulation E, the United States federal regulation implementing the Electronic Fund Transfer Act, establishes a framework for protecting consumers who transfer funds electronically and sets out the error-resolution obligations a financial institution must follow when investigating a disputed transaction. Regulation E requires a determination of whether an error occurred within 10 business days of receiving a consumer’s notice of error. If further investigation is required, Regulation E permits up to 45 days to do so, but only if the consumer is provided provisional credit for the disputed amount within the first 10 business days. Marqeta offers investigation and resolution services for Regulation E disputes. The party responsible for these services is determined by the terms of your contract. Refer to your agreement to confirm which party is responsible.

​

Distinguishing Regulation E and Regulation Z disputes

Regulation E applies to disputes involving electronic fund transfers from a deposit or prepaid account. Regulation Z governs billing-error disputes on credit accounts. For details on the credit account dispute process, see About Regulation Z. The regulation_type field of a dispute case is set to REG_E only for disputes created against a debit or prepaid funding source through the /cases endpoint.

​

Intake of disputes

Programs must be able to accept a cardholder’s notice of error both orally (for example, by phone) and in writing. Marqeta does not require a program to obtain a written confirmation of an oral notice of error before submitting the dispute case. When you create a Regulation E dispute case using the /cases endpoint, the following fields are required:

• original_transaction_token: The token of the transaction being disputed.
• dispute_reason: The reason code that applies to the cardholder’s situation. For more information on reason codes, see Dispute case reasons (Mastercard), Dispute Reason Codes (Visa), Transition Reason Code (Pulse).
• cardholder_contact_date: The date the cardholder’s notice of error was received. This date establishes the start of the applicable Regulation E timelines.

Additional fields might be required depending on the card network and dispute reason code. For the full payload reference, see Creating a Dispute.

​

Notice of error timing

Regulation E requires a consumer to submit a notice of error no later than 60 days from when the statement is sent. The cardholder_contact_date field you provide when creating a Regulation E dispute case establishes both the start of the 45-day investigation clock described below and the reference point for evaluating whether the notice of error was submitted within the regulatory window.

​

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 the notice of error is received from the consumer. The 45-day clock begins on the cardholder contact date. 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 network 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, provisional credit must be granted within 10 business days of the cardholder_contact_date. It depends on the dispute model whether you or Marqeta is responsible for granting the provisional credit. The Disputes portal provides a warning if the 10-business-day timeline for providing provisional credit is expiring. You can look up the expiration date for one-off cases when the milestone is PENDING_PC_GRANTED for the PROVISIONAL_CREDIT subcategory. To do this use the GET /cases/{token}/milestones endpoint. For all programs on Marqeta’s Regulation E platform, either provisional credit is granted automatically or a webhook is sent on or before the 9th business day to ensure compliance with Regulation E timing requirements. Marqeta does not send the webhook if provisional credit is granted before the 9th business day.

​

Granting provisional credit

To grant provisional credit, use the POST /cases/{token}/actions endpoint with GRANT_PROVISIONAL_CREDIT as the action_type. The provisional credit can be granted while the dispute case is 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 also triggers the authorization.clearing.chargeback.provisional.credit webhook.

​

Notifying the cardholder of provisional credit

Regulation E requires that the cardholder be notified of the amount and date of a provisional credit within two business days after the credit is granted. When you call GRANT_PROVISIONAL_CREDIT, Marqeta sends the authorization.clearing.chargeback.provisional.credit webhook, which you can use to trigger this notice.

​

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

If the chargeback is rejected by the card network, Marqeta, as the party responsible for handling the regulatory aspect of the claim, evaluates that rejection to determine how the provisional credit should be handled. Marqeta evaluates the rejection together with the results of a reasonable investigation guided by the application parameters established by your program. For example, whether the disputed amount should be a writeoff. This assessment results in one of the following outcomes:

• Cardholder keeps the provisional credit: Marqeta’s investigation, considered alongside the network rejection and applicable program parameters, results in a determination that the cardholder should keep the provisional credit. In this scenario, Marqeta closes the case with a writeoff to the program.
• Cardholder does not keep the provisional credit: Marqeta’s investigation, considered alongside the network rejection and applicable program parameters, results in a determination that the cardholder should not keep the provisional credit. In this scenario, Marqeta closes 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.
• No error occurred, but 45 calendar days have passed: The investigation, together with the network rejection, determines that no error occurred, but the case has been open for more than 45 calendar days. In this scenario, Marqeta closes the case with a writeoff to the program, given that the credit has already been made permanent.

If a case is rejected by the card network, Marqeta receives the reason for rejection, provides it to you using the regulation.network.rejected webhook, and moves the case to the OPEN_WITH_ACTION_REQUIRED state. Marqeta evaluates the card network rejection together with its own investigation of the claim and the applicable program parameters, and determines whether the dispute should be resubmitted and how the provisional credit should be resolved. Where a claim is resubmitted, Marqeta continues to persist the provisional credit against the customer account. The cardholder is always notified of the final decision within three business days. For a card network rejection use case, see Post-network submission – card network rejection.

​

Pre-network submission cases

After investigating a dispute case that the card network rejected, you can withdraw and close the case before resubmission if you determine that the case is lost. For this use case, see 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 business days in advance that the credit will be reversed. The notification should specify the date and the amount of the reversal.
• Trigger an event with the date of notification.
• Wait five business 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 the date you notified them, otherwise the system does not process the reversal. Marqeta reverses 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

If the program is responsible for cardholder communications, once you notify the cardholder, you must trigger a CaseLostNotificationSent event and specify the date when you notified the cardholder in 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 moves the milestone from CASE_LOST_PENDING_COMMS to CASE_LOST_COMMS_EXPIRED. In this scenario, you can no longer change the next_milestone_due_date for the PENDING_PC_REVERSAL. Failing to send the CaseLostNotificationSent event results in permanent credit to the cardholder.

​

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. When you manage the cardholder communication, it is your responsibility to inform Marqeta of the date of the provisional credit perm confirmation and that the Case Won confirmation was sent to the cardholder. This confirmation serves as Marqeta’s record that the error has been corrected and that the cardholder has been informed of the correction, consistent with Regulation E’s error-correction requirements. Separately, once a determination is made that an error occurred, Regulation E requires the error to be corrected within one business day of that determination. 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. This confirmation serves the same error-correction notice purpose described in Case won.

​

Reporting investigation results

Once a Regulation E case is resolved, the cardholder must be informed of the outcome and any impact to their account in a timely manner, including:

• The determination of whether an error occurred.
• The amount and date of any credit or debit adjustment made to the account.
• The cardholder’s right to request the documents Marqeta relied on in reaching its determination.

Regulation E requires that the cardholder be notified of the investigation results within three business days of Marqeta completing its investigation, whether the case is won or lost. Marqeta sends the regulation.case.won, regulation.case.lost.action.required, and regulation.provisional.credit.permanent webhooks to notify you of each outcome so that you can meet this notice obligation. See Notifying the cardholder in About Disputes for example cardholder communication templates.

​

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 – 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 – 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.