> ## Documentation Index
> Fetch the complete documentation index at: https://www.marqeta.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# 2025

<Update label="July 2025">
  ### New features

  #### New BIN attack mitigation feature to enhance issuer fraud controls

  As part of the continued evolution of our services and our efforts to minimize cardholder fraud, Marqeta is planning to roll out a BIN attack mitigation feature within our [Real-Time Decisioning platform](/docs/developer-guides/real-time-decisioning-landing-page/) in the near future.

  Our new BIN attack detection capability will leverage real-time transaction data across our issuer network to detect patterns consistent with enumeration or brute-force behavior.

  Key capabilities include:

  * Velocity-based triggers, for example, an unusual surge in authorization attempts by BIN
  * Automated decline or soft-block logic on merchants experiencing high-risk attempts
  * Program-configurable controls to tailor protection thresholds
  * Proactive alerts to fraud teams upon detection of BIN attack attempts

  By leveraging these capabilities, Marqeta's Real-Time Decisioning customers will be able to proactively block transactions occurring on merchants who may be experiencing a BIN attack. This enhanced functionality will help protect your cardholders from possible financial losses.

  To enable this feature, contact your Marqeta representative.
</Update>

<Update label="June 2025">
  ### New features

  #### New Mastercard chargeback reject code

  Marqeta now displays Mastercard's new chargeback reject code, `5002`, in the Marqeta Dashboard when a merchant provides compelling evidence that the cardholder had authorized the disputed transaction.

  For more information on Mastercard disputes, see [Managing Mastercard Disputes](/docs/developer-guides/managing-mastercard-disputes/).

  #### New document retrieval button in the Marqeta Dashboard

  Marqeta's disputes system automatically downloads all merchant documents provided in Mastercard's representments. However, the disputes system does not automatically check for documents that were submitted after the initial representment was filed.

  To ensure all representments include the required merchant documents, the Marqeta Dashboard now provides a self-serve **Retrieve Network Documents** button if no documents were submitted in the initial representment. When an agent clicks the button, the disputes system will search Mastercard for any newly added documents, then download them to the Marqeta Dashboard.

  To get started with the Marqeta Dashboard and explore this new feature, see [Dashboard Overview and Quick Start](/docs/developer-guides/dashboard-overview-and-quick-start/). For more information on representments, see the [Representment](/docs/developer-guides/about-disputes/#_representment) section of the [About Disputes](/docs/developer-guides/about-disputes/) guide.

  #### Viewable case notes in the Marqeta Dashboard

  Marqeta now allows agents to compose multiple notes that pertain to a specific dispute case. These notes are now viewable in the Marqeta Dashboard.

  This enhancement is designed to provide you with a comprehensive context of what is happening on a dispute case, allowing you to easily track its progress and submit it accordingly, all without leaving the Marqeta Dashboard.

  To get started with the Marqeta Dashboard and explore this new feature, see [Dashboard Overview and Quick Start](/docs/developer-guides/dashboard-overview-and-quick-start/).

  #### New intake questions for disputed transactions

  In accordance with Visa's network changes, Marqeta has added new disputes questions to the Disputes API and the Marqeta Dashboard:

  * API users must update their case creation API contracts in order to support these new questions in the intake process.
  * Marqeta Dashboard users must collect additional information from cardholders during the intake process. The Marqeta Dashboard has already been updated with the necessary changes.

  #### New field in 3DS SCA challenge result request object

  Effective 30 June 2025, Marqeta will add a new optional field called `card_token` to the `ThreeDSChallengeResultRequest` object. In this field, you can input the Marqeta-assigned unique card token that identifies the card being used.

  For more information, see the [ThreeDSChallengeResultRequest object](/docs/core-api/3ds/#_the_threedschallengeresultrequest_object).
</Update>

<Update label="May 2025">
  ### New features

  #### Dispute reason codes can be modified in some states

  Dispute risk analysts can now modify the [dispute reason code](/docs/developer-guides/disputes-dashboard/#_dispute_reasons_and_codes) when a case is in one of the following states:

  * `Open`
  * `Open with action required`
  * `Ready` (if the case is in the `Ready` state, move it to `Open`, make the change, then move it back to `Ready`)

  This enhancement increases efficiency, because agents no longer need to close the current dispute, then open a new one and re-enter the case details. It can also lead to a reduction in duplicate cases.

  <Note>
    **Note**<br />This update applies to the following dispute types:

    * **Integrated:** Disputes for which the process is automated and managed through the card network's system.
    * **Non-integrated:** Disputes for which the process is manually managed by Marqeta.
  </Note>

  The table below summarizes the supported reason changes from a regulatory perspective. Attempting to make an unsupported reason change will raise an error if made by API, and will be unavailable in the Marqeta Dashboard.

  <div className="release-notes-dispute-reason-changes-table">
    <table class="auto-layout">
      <thead>
        <tr>
          <th>Previous Reg Type</th>
          <th>Current Reg Type</th>
          <th>Requirements and Guidelines</th>
        </tr>
      </thead>

      <tbody>
        <tr>
          <td>Regulation</td>
          <td>Regulation</td>
          <td>Change is allowed; add an entry in the case transition to capture the change.<br /><br />**Example:**<br />Updating the dispute reason code from `10.3` to `10.4`.<br /><br />**NOTE:** This change applies to both Reg E → Reg E and Reg Z → Reg Z.</td>
        </tr>

        <tr>
          <td>No Regulation</td>
          <td>No Regulation</td>
          <td>Change is allowed; add an entry in the case transition to capture the change.<br /><br />**Example:**<br />Updating the dispute reason code from `13.1` to `13.7`.</td>
        </tr>

        <tr>
          <td>Regulation (with provisional credit)</td>
          <td>No Regulation</td>
          <td>Change is allowed, but must be treated as a Regulation case, following the milestones for the Regulation-to-Regulation change. Add an entry in the case transition to capture the reason change.<br /><br />**Example:**<br />Updating the dispute reason code from `10.4` to `13.1`.<br /><br />**NOTE:** The provisional credit must remain unchanged.</td>
        </tr>

        <tr>
          <td>No Regulation</td>
          <td>Regulation</td>
          <td>Change is allowed, but must be treated as a Regulation case, following the milestones for the Regulation-to-Regulation change. Add an entry in the case transition to capture the reason change. Follow the regulatory clock, based on the cardholder contact date.<br /><br />**Example:**<br />Updating the dispute reason code from `13.7` to `10.4`.<br /><br />**NOTE:** Milestones for Regulation disputes are set during case creation only. Because this change occurs after case creation, the Regulation flow must be modified.</td>
        </tr>

        <tr>
          <td>Regulation (no provisional credit)</td>
          <td>No Regulation</td>
          <td>Treat changing these disputes like you would a type non-Reg E dispute.<br /><br />A provisional credit has not been granted in this scenario, and you are therefore not restricted to issuing a provisional credit based on the original reason code. You should issue a provisional credit based on the cardholder's statement and the facts of the case.<br /><br />Milestones for Regulation disputes are set during case creation only. A pre-initiation state change and `auth.clearing.chargeback` webhooks are sent during case creation.<br /><br />To accommodate the change, you will need to "delete" milestones and "withdraw" the case to reverse the `auth.clearing.chargeback` webhook that was originally sent.</td>
        </tr>

        <tr>
          <td>Reg E</td>
          <td>Reg Z</td>
          <td>Change is allowed, but you must replace the configured milestones. Add an entry in the case transition to capture the reason change.<br /><br />**Example:**<br />Buy Now, Pay Later (BNPL) transactions.<br /><br />**NOTE:** Configuration milestones are set during case creation.</td>
        </tr>
      </tbody>
    </table>
  </div>

  #### Fraud mitigation for token provisioning

  To help mitigate account takeover (ATO) fraud, Marqeta is offering a new enhancement in the identification and verification (IDNV) process during token provisioning. This feature focuses on compliance and security and is available globally.

  You can now tailor your designated identity verification methods, by disabling specific methods per token provisioning type, to meet your organization's policies. For example, you can exclude the SMS One-Time Password (OTP) method for manual token provisioning, but keep it active for other provisioning types.

  Contact your Marqeta representative if you would like to update your IDNV settings for token provisioning. See [Provisioning Digital Wallet Tokens](/docs/developer-guides/provisioning-digital-wallet-tokens/) for more information about token provisioning.

  ### Enhancements

  #### Improved dispute creation experience for Pulse transactions

  Marqeta has implemented changes to the Marqeta Dashboard to enhance the dispute creation experience for Pulse transactions.

  Previously, to create a dispute for a Pulse transaction within the Marqeta Dashboard, users had to select "Other" and input all the relevant information in the "memo" field. Now, users can select the applicable reason codes and input information into the appropriate fields. This change streamlines the dispute creation process and makes it more efficient.

  To get started with the Marqeta Dashboard and explore these new features, see [Dashboard Overview and Quick Start](/docs/developer-guides/dashboard-overview-and-quick-start/).

  #### Dispute intake integration available for additional Visa reason codes

  Dispute intake integration is now available for the following Visa reason codes that were previously non-integrated:

  * `11.2` Declined authorization
  * `12.7` Invalid data
  * `13.4` Counterfeit merchandise
  * `13.5` Misrepresentation
  * `13.7` Cancelled merchandise/services
  * `13.8` Original credit not accepted

  You can now use an API call or the Marqeta Dashboard and select the reason code to file a dispute instead of changing the dispute type to `LEGACY_DISPUTE` or `OTHER` in the Marqeta Dashboard.
</Update>


## Related topics

- [2025](/docs/developer-guides/ux-toolkit-release-notes/2025.md)
- [Card Network Certifications 2025](/docs/developer-guides/card-network-certifications-2025.md)
- [Release Notes](/docs/developer-guides/release-notes-2025.md)
- [Account & Money Movement Release Notes](/docs/developer-guides/account-money-movement-release-notes/2025.md)
- [Credit Release Notes](/docs/developer-guides/credit-release-notes/2025.md)
