We're reclaiming inactive PDIs to keep them available for active builders. Learn what's changing, who's affected, and how to protect your work. Read More

Mastercard Disputes Management: Consolidated Release Notes

timothychang
ServiceNow Employee

2 hours ago - edited 2 hours ago

Mastercard Disputes Management: Enhancement Overview

Objective

This article provides a consolidated, release by release overview of enhancements delivered to Mastercard disputes management within Financial Services Operations (FSO), covering the February 2025 release through the July 2026 release. It is intended for existing FSO Disputes customers, administrators, and implementers who need to track what changed in each release, including new capabilities, data model updates, workspace changes, and defect corrections that may affect existing configurations or customizations. If you are new to FSO Disputes, start with Getting Started with FSO Disputes for foundational context before working through the releases below. Use the table of contents to jump directly to a release or application.

Release: February 2025

App: Financial Services Operations Core

Data model

  • Card Disputes Transaction table reparented to Financial Task table. During upgrade to Yokohama, the Card Disputes Transaction table (sn_bom_credit_card_disputes_transaction) is reparented to the Financial Task table (sn_bom_task) in FSO Core. Instances with large datasets may experience increased upgrade times. Customizations referencing this table directly should be reviewed before upgrading.
  • Claim Base table: SIU review, validation decision, and fraud decision fields added. Three fields previously scoped to specific applications (SIU review, Claim validation decision, and Claim fraud decision) are now available at the shared Claim Base table level, enabling consistent reporting and cross-application workflows.
  • Shipping address fields added to FSO Core data model. New fields on the Financial Transaction record store delivery address data returned from Visa's Cardholder Purchase Inquiry API. These fields are visible in the friendly fraud review workflow and allow agents to compare the merchant's stated delivery address against cardholder claims during investigation.

↑ Back to top

Release: May 2025

App: Mastercard Spoke

Spoke configuration

  • Mastercard Spoke v3.0.0: Mastercom Extended API integration. A new layer of Mastercom Extended API spoke actions was delivered, enabling dispute management for cleared Single Message System (SMS) transactions. This was a net new API suite distinct from the existing Mastercom API Suite (v6), covering the full dispute lifecycle from claim creation through arbitration, document management, queue processing, fraud reporting, and transaction search. The following actions were added.

Claim management

  • Mastercom Extended: Create New Claim. Creates a new dispute claim in the Mastercom Extended system for a cleared SMS transaction.
  • Mastercom Extended: Retrieve Claim Details, Request Builder. Builds the API request to retrieve the details of an existing claim by claim ID.
  • Mastercom Extended: Retrieve Claim Details, Response Parser. Parses the claim detail response, including claim status, transaction data, and associated documentation references.
  • Mastercom Extended: Retrieve List of Claims. Retrieves a list of claims from Mastercom Extended, supporting bulk investigation and queue management workflows.
  • Mastercom Extended: Retrieve List of Claims in a Queue. Retrieves claims currently held in a specific Mastercom processing queue.
  • Mastercom Extended: Update Representment by Claim ID and Event ID. Updates an existing representment submission for a claim, identified by both the claim ID and the event ID.
  • Mastercom Extended: Initiate a Dispute (Chargeback) by Claim ID. Initiates a formal chargeback for an existing claim, triggering the Mastercard chargeback process.

Case filing, pre-arbitration, arbitration, and compliance

  • Mastercom Extended: Create Pre-Arbitration or Arbitration Case. Creates a pre-arbitration or arbitration case in Mastercom Extended, advancing a dispute beyond the initial chargeback stage.
  • Mastercom Extended: Update or Respond to Pre-Arbitration or Arbitration Case. Submits an issuer response to an existing pre-arbitration or arbitration case, including acceptance, rebuttal, or escalation.
  • Mastercom Extended: Create Pre-Compliance or Compliance Case. Creates a pre-compliance or compliance case in Mastercom Extended for disputes that involve a rules violation rather than a standard chargeback pathway.
  • Mastercom Extended: Update or Respond to Pre-Compliance or Compliance Case. Submits an issuer response to an existing pre-compliance or compliance case. The rebuttal party field now includes a "none" option for cases where the field is not applicable, as required by the Mastercom API.
  • Mastercom Extended: Retrieve Details for an Existing Case. Retrieves the current details of a pre-arbitration, arbitration, pre-compliance, or compliance case by case identifier.

Document management

  • Mastercom Extended: Attach Document by Case ID. Attaches a supporting document to an existing Mastercom Extended case using the case identifier.
  • Mastercom Extended: Attach Documents by Claim ID and Event ID. Attaches one or more documents to a claim at a specific event stage, identified by both the claim ID and the event ID.
  • Mastercom Extended: Upload Documents. Uploads documents directly to the Mastercom Extended system for association with claims or cases.
  • Mastercom Extended: Retrieve Processed Documents. Retrieves documents that have been processed and accepted by Mastercom for a given claim or case.
  • Mastercom Extended: Check Document Details. Retrieves metadata and processing status for a specific document submitted to Mastercom Extended.
  • Mastercom Extended: Retrieve Document Statuses Associated with Cases. Retrieves the processing status of all documents associated with a given case, supporting document completeness checks before escalation.

Queue management

  • Mastercom Extended: Retrieve List of Queues. Retrieves the full list of available Mastercom processing queues, supporting queue based workflow routing.
  • Mastercom Extended: Retrieve Queue Fields. Retrieves the field definitions for a specific Mastercom queue, enabling dynamic queue data mapping in subflows.

Fraud reporting

  • Mastercom Extended: Create Fraud Report. Submits a new fraud report to Mastercard through the Mastercom Extended fraud reporting system.
  • Mastercom Extended: Search for Fraud Report / Retrieve Report Status. Searches for existing fraud reports and retrieves the current status of a submitted report.
  • Mastercom Extended: Retrieve Completed Reports. Retrieves fraud reports that have completed processing in the Mastercom system.
  • Mastercom Extended: Retrieve Report Field Definitions. Retrieves the field definitions required when constructing a fraud report submission, supporting dynamic form building.

Transaction search

  • Mastercom Extended: Look Up Transactions, Request Builder. Builds the API request to search for cleared SMS transactions in the Mastercom Extended system.
  • Mastercom Extended: Look Up Transactions, Response Parser. Parses the transaction search results returned by Mastercom, including transaction details and associated card data.

Chargeback

  • Mastercom Extended: Reverse a Chargeback. Submits a chargeback reversal to Mastercom Extended, used when an issuer withdraws a previously filed chargeback.
  • Path variable support added to Mastercom Extended request builders. Spoke action request builders were updated with path variable support, allowing administrators to pass dynamic case and claim IDs as inputs when configuring spoke actions in Flow Designer. Previously, these identifiers had to be hardcoded in the action configuration.

↑ Back to top

Release: August 2025

App: Mastercard Spoke

Spoke configuration

  • Mastercard Spoke v4.0.0: Mastercom Case Filing. New spoke actions were added for the Mastercom API Suite v6 endpoints, enabling pre-arbitration and arbitration case filing for dual-message transactions. Combined with the Mastercom Extended suite (v3.0.0), the Mastercard Spoke now covers both SMS and dual-message dispute scenarios.

Mastercom APIs

  • Mastercom v6: Create Case, Request Builder. Builds the API request to create a pre-arbitration or arbitration case via the Mastercom v6 POST /v6/cases endpoint.
  • Mastercom v6: Create Case, Response Parser. Parses the case creation response, including the assigned case ID and initial case status.
  • Mastercom v6: Take Action on Case, Request Builder. Builds the API request to take a defined action on an existing case: accept, reject, rebut, escalate, or withdraw.
  • Mastercom v6: Take Action on Case, Response Parser. Parses the response returned after taking action on a Mastercom case.
  • Mastercom v6: Look Up Case Document Status. Retrieves the processing status of documents associated with a Mastercom v6 case, confirming whether submitted documents have been accepted or require resubmission.
  • Mastercom v6: Retrieve Documents Under a Case. Retrieves documents filed under a specific Mastercom v6 case for display in the dispute workspace.
  • Mastercom v6: Look Up Chargeback Documents, Request Builder. Builds the API request to retrieve chargeback related documents from the Mastercom v6 system.
  • Mastercom v6: Look Up Chargeback Documents, Response Parser. Parses the chargeback document response returned by the Mastercom v6 API.
  • Mastercom v6: Look Up List of Claims Associated with Cases. Retrieves the list of claims linked to an existing Mastercom case, supporting case management and workspace display.
  • Mastercom v6: Health Check for Mastercom APIs. Checks the availability and responsiveness of the Mastercom APIs, enabling real time integration health monitoring for operational teams.
App: FSO Integration with Mastercard

Subflows

  • FSO Integration with Mastercard: new application (initial subflows). A new application was introduced as the integration layer between the Mastercard Spoke and FSO Card Operations workflows. The following subflows were delivered in the initial August 2025 release.
  • FSO-Mastercard: Standard Transaction Lookup subflow. Retrieves standard transaction details from Mastercom for a given dispute transaction, pre-populating the dispute workspace with card and transaction data.
  • FSO-Mastercard: Clearing Transaction Lookup subflow. Retrieves clearing transaction details from Mastercom for a given dispute, supporting cleared transaction dispute investigations.
  • FSO-Mastercard: Fraud Report Creation subflow. Submits a fraud report to Mastercard from within the FSO dispute workflow.
  • FSO-Mastercard: Claim Creation subflow. Creates a new Mastercom claim linked to a dispute transaction.
  • FSO-Mastercard: Claim Validation subflow. Validates an existing claim against Mastercom eligibility rules before chargeback is initiated.
  • FSO-Mastercard: Create Chargeback subflow. Initiates a chargeback in Mastercom for an eligible disputed transaction.
  • FSO-Mastercard: Acknowledge Chargeback subflow. Acknowledges a received chargeback in Mastercom, confirming the issuer's awareness of the dispute event.
  • FSO-Mastercard: Update Chargeback subflow. Updates an existing chargeback record in Mastercom with revised information or supporting documents.
  • FSO-Mastercard: Look Up Chargeback Details subflow. Retrieves the current details of a chargeback from Mastercom, including status and associated events.
  • FSO-Mastercard: Look Up Chargeback Documents subflow. Retrieves documents associated with a chargeback from Mastercom.
  • FSO-Mastercard: Look Up Second Presentment Details subflow. Retrieves second presentment information from Mastercom when a merchant challenges an initial chargeback.
  • FSO-Mastercard: Reverse Chargeback subflow. Submits a chargeback reversal to Mastercom when the issuer withdraws a previously filed chargeback.
  • FSO-Mastercard: Process Pending Documentation Queue subflow. Processes the Mastercom pending documentation queue on a full run basis, ensuring all items are worked on each scheduler execution regardless of API timestamp reliability.
  • FSO-Mastercard: Process Issuer Worked Queue subflow. Processes the Mastercom issuer worked queue to advance dispute tasks that have been acted upon by the issuer.
  • FSO-Mastercard: Process Reject Queue subflow. Processes the Mastercom reject queue, handling dispute items that were rejected by Mastercard.
  • FSO-Mastercard: Process Issuer Re-Presentment Unworked Queue subflow. Processes the Mastercom re-presentment unworked queue for items requiring issuer action.
  • FSO-Mastercard: Process Sender Case Filing Queue subflow. Processes the Mastercom sender case filing queue for disputes requiring case filing actions.
  • FSO-Mastercard: Case Filing, Create subflow. Initiates a new case filing in Mastercom through the FSO dispute workflow.
  • FSO-Mastercard: Case Filing, Take Action subflow. Takes a defined action on an existing Mastercom case from within the FSO dispute workspace.
  • FSO-Mastercard: Case Filing, Look Up Documents subflow. Retrieves documents associated with a Mastercom case filing.
  • FSO-Mastercard: Case Filing, Look Up Status subflow. Retrieves the current processing status of a Mastercom case filing.
  • FSO-Mastercard: Claim List Lookup subflow. Retrieves a list of Mastercom claims associated with a dispute for workspace display and triage.
  • FSO-Mastercard: Mastercom queue processing operates on full run scheduler basis. Mastercom queues are processed completely on each scheduled run rather than incrementally by date. This change was made because Mastercom's queue lastModifiedDate timestamps are not reliably populated. Dispute cases are always current with the latest Mastercom queue data regardless of API timestamp accuracy.
  • FSO-Mastercard: Work notes restricted to integration failures only. Work notes on dispute tasks are now generated only when a Mastercom API call fails. Previously, every API interaction, including successful calls, posted a work note, creating noise in the task activity stream. Agents now see a cleaner audit trail focused on errors that require action.

Document handling

  • FSO-Mastercard: DOC_NOT_APPLICABLE document status now recognised. When Mastercom returns a DOC_NOT_APPLICABLE status for a document type, task state is now correctly updated. Previously, this status caused task processing errors because it was not a recognised value in the document queue handling logic.
App: Financial Services Card Operations

Workspace

  • Mastercard disputes workspace: new end-to-end workspace. A new dispute management workspace was introduced for Mastercard disputes, providing a purpose built environment for the full chargeback lifecycle including pre-arbitration and arbitration. The workspace uses a process based stage layout (Investigate, Chargeback, Closure) consistent with the Visa dispute workspace layout.
  • Mastercard dispute workspace: default Attachments tab suppressed. The platform's default Attachments tab is suppressed in the Mastercard dispute workspace. Documents are managed exclusively through the custom document handling flow. Agents who previously relied on the out-of-the-box attachments panel should use the dispute task's document attachment component instead.
  • Mastercard dispute workspace: Escalate to Arbitration as discrete outcome. Escalate to Arbitration is now a discrete outcome choice available to agents on the Review Pre-Arbitration Response task, rather than a separate workflow trigger. Selecting it closes the pre-arbitration task and opens the arbitration task, making the escalation path intentional and visible.

Data model

  • L1/L2 dispute category and reason code derived via three step decision table chain. The dispute category and chargeback reason code are now derived automatically through a three step decision table sequence: determine the dispute category, derive available reason options for that category, and confirm the reason code. When no card network specific content pack is installed, a fallback decision table provides network agnostic reason code derivation.
App: Financial Services Operations Core

Data model

  • Payment Card Application: store card details across the full card lifecycle. A new Payment Card Application enables storage of physical payment card details, including tokenized PAN values, across the full card lifecycle. Supports both credit and debit card types. A Payment Card reference field was added to the Financial Transaction table to link transactions to their associated card record.
  • Issuer ICA and Acquirer ICA fields added to Financial Transaction table. The Interbank Card Association (ICA) numbers for the issuing and acquiring banks are now stored on the Financial Transaction record. These fields are required by the Mastercom case filing API and must be populated before a case can be filed with Mastercard.

↑ Back to top

Release: December 2025

App: FSO Integration with Mastercard

Subflows

  • FSO-Mastercard: embedded Mastercom v6 lifecycle subflows. 19 Mastercom API Suite (v6) subflows were embedded directly into the card dispute workspace, meaning agents triggering chargeback, pre-arbitration, and arbitration actions execute live Mastercom API calls transparently from the workspace.
  • FSO-Mastercard: Create Chargeback (v6). Submits a new chargeback to Mastercard via POST /v6/claims/{claim-id}/chargebacks.
  • FSO-Mastercard: Create Second First Chargeback (v6). Submits a second first chargeback when a prior chargeback has been reversed and a new one must be filed.
  • FSO-Mastercard: Reverse Chargeback (v6). Submits a chargeback reversal via the Mastercom v6 reversal endpoint.
  • FSO-Mastercard: Receive Second Presentment Details (v6). Retrieves second presentment information from the Mastercom v6 claim endpoint when a merchant responds to a chargeback.
  • FSO-Mastercard: Update Credit Voucher Status (v6). Updates the credit voucher status in Mastercom after the dispute is resolved in the issuer's favour.
  • FSO-Mastercard: File Pre-Arbitration or Arbitration Case (v6). Files a pre-arbitration or arbitration case via the Mastercom v6 POST /v6/cases endpoint from within the dispute workspace.
  • FSO-Mastercard: Withdraw from Case (v6). Submits a case withdrawal to Mastercom through the Take Action on Case endpoint.
  • FSO-Mastercard: Escalate to Arbitration (v6). Escalates an existing pre-arbitration case to full arbitration through the Take Action on Case endpoint.
  • FSO-Mastercard: Retrieve Pre-Arbitration Response Details (v6). Retrieves the merchant's response to a pre-arbitration filing from Mastercom.
  • FSO-Mastercard: Retrieve Arbitration Response Details (v6). Retrieves the outcome and details of an arbitration proceeding from Mastercom.
  • FSO-Mastercard: Handle 5002 Reject Reason Code. Handles the edge case where a merchant submission is rejected by Mastercard with a 5002 code, routing the dispute to the appropriate recovery path.
  • FSO-Mastercard: Handle Revised Pre-Arbitration Merchant Response. Handles the edge case where a merchant revises their pre-arbitration response after initial submission, ensuring the dispute workspace reflects the latest merchant position.
  • FSO-Mastercard: Update Mastercard Chargeback Reason Code List. Refreshes the chargeback reason code reference data in FSO from the Mastercom system to keep reason code choices current.
  • FSO-Mastercard: Authorization Transaction Lookup subflow. Retrieves authorization details related to a dispute transaction from Mastercom, supporting chargeback eligibility rule evaluation.
  • FSO-Mastercard: Claim Details Lookup subflow. Retrieves the full claim record from Mastercom for display and eligibility checking.
  • FSO-Mastercard: Action on Existing Claim subflow. Takes a defined action on an existing Mastercom claim from within the dispute workflow.
  • FSO-Mastercard: Pending Queue Processing subflow. Processes pending Mastercom queue items in a full run batch execution.
  • FSO-Mastercard: Chargebacks-related Information Lookup subflow. Retrieves chargeback history and related event information from Mastercom for a given claim.
  • FSO-Mastercard: Fraud-related Information Lookup subflow. Retrieves fraud case data and related information from Mastercom to support investigation.
  • FSO-Mastercard: Chargeback Reversal subflow. Submits a chargeback reversal to Mastercom as a discrete subflow callable from multiple workflow contexts.

Document handling

  • FSO-Mastercard: Look Up Case Documents (v6). Retrieves documents associated with a Mastercom v6 case for display in the workspace.
  • FSO-Mastercard: Update Document via Mastercom (v6). Submits updated or replacement documentation to Mastercom through the Take Action on Case and Update Chargeback endpoints.

Workspace

  • FSO-Mastercard: Embed Mastercard Integration into Workspace. Connects the embedded Mastercom v6 lifecycle subflows to the dispute workspace, enabling agents to trigger chargeback, case filing, and arbitration actions directly from workspace tasks.
App: Dispute Rules Content Pack for Mastercard

Chargeback eligibility rules

  • Dispute Rules Content Pack for Mastercard: initial release. A new application delivering Mastercard chargeback eligibility rules as decision tables and subflows. The initial release covered the following reason code categories in full.
  • Eligibility rules, RC 4853 DGP: Digital Goods Purchase. Decision table and subflow covering eligibility conditions for chargebacks involving digital goods purchases.
  • Eligibility rules, RC 4853 TESNR: Travel/Entertainment Services Not Provided. Decision table and subflow covering eligibility conditions for chargebacks where travel or entertainment services were not delivered.
  • Eligibility rules, RC 4853 CDORT: Cardholder Dispute of Recurring Transaction. Decision table and subflow covering eligibility conditions for chargebacks where a cardholder disputes a recurring charge they did not authorise or cancel.
  • Eligibility rules, RC 4853 IDORT: Issuer Dispute of Recurring Transaction. Decision table and subflow covering eligibility conditions for chargebacks where the issuer disputes a recurring transaction on behalf of the cardholder.
  • Eligibility rules, RC 4853 ADD: Addendum Dispute. Decision table and subflow covering eligibility conditions for chargebacks arising from additional charges added to an original transaction without authorisation.
  • Eligibility rules, RC 4853 NOSHC: No-Show Hotel Charge. Decision table and subflow covering eligibility conditions for hotel no-show chargebacks, including cancellation policy and documentation requirements.
  • Eligibility rules, RC 4853 TDNC: Transaction Did Not Complete. Decision table and subflow covering eligibility conditions for chargebacks where the transaction did not complete at the point of interaction.
  • Eligibility rules, RC 4853 Timeshares. Decision table and subflow covering eligibility conditions for chargebacks arising from timeshare purchases.
  • Eligibility rules, RC 4853 GOS: Goods or Services Not Provided. Decision table and subflow covering eligibility conditions for chargebacks where the merchant did not deliver the purchased goods or services.
  • Eligibility rules, RC 4853 GOSWEN: Goods or Services Not as Described. Decision table and subflow covering eligibility conditions for chargebacks where goods or services differed materially from the merchant's description.
  • Eligibility rules, RC 4853 CG: Counterfeit Goods. Decision table and subflow covering eligibility conditions for chargebacks involving counterfeit merchandise.
  • Eligibility rules, RC 4853 RNP: Credit Not Processed. Decision table and subflow covering eligibility conditions for chargebacks where a merchant credit was not applied to the cardholder's account.
  • Eligibility rules, RC 4853 RPAP: Credit Posted as Purchase. Decision table and subflow covering eligibility conditions for chargebacks where a credit transaction was posted as a debit.
  • Eligibility rules, RC 4853 T&ES: Travel/Entertainment Services (general). Decision table and subflow covering general eligibility conditions for travel and entertainment chargebacks not covered by more specific T&E sub-categories.
  • Eligibility rules, RC 4834 Charges for Loss, Theft, or Damages. Decision table and subflow covering eligibility conditions for chargebacks where a merchant charged a cardholder for loss, theft, or damage without authorisation.
  • Eligibility rules, RC 4834 Improper Merchant Surcharge. Decision table and subflow covering eligibility conditions for chargebacks arising from surcharges applied by the merchant that do not comply with Mastercard rules.
  • Eligibility rules, RC 4834 Unreasonable Amount. Decision table and subflow covering eligibility conditions for chargebacks where the transaction amount was unreasonably higher than the goods or services provided.
  • Eligibility rules, RC 4834 Currency Errors. Decision table and subflow covering eligibility conditions for chargebacks arising from currency conversion errors at the point of interaction.
  • Eligibility rules, RC 4834 MRCERICCEXL: Merchant Refund Correcting Error Resulting in Currency Exchange Loss. Decision table and subflow covering eligibility conditions for chargebacks where a merchant refund was processed in a way that caused a currency exchange loss for the cardholder.
  • Eligibility rules, RC 4834 Cardholder Debited More Than Once. Decision table and subflow covering eligibility conditions for duplicate debit chargebacks where the cardholder was charged multiple times for the same transaction.
  • Eligibility rules, RC 4834 TAD: Transaction Amount Differs. Decision table and subflow covering eligibility conditions for chargebacks where the settled amount differs from the authorised amount. A correction was also applied to address a missing MCC 6011 condition for non-China AcceptorCountryCode combinations, which was causing inaccurate eligibility guidance for ATM cash dispensing transactions.
  • Eligibility rules, RC 4834 ATM Funds Not Dispensed. Decision table and subflow covering eligibility conditions for chargebacks where a cardholder was debited but did not receive cash from an ATM.

Reason codes

  • Chargeback Reason Code Message decision table. Derives the human readable chargeback reason code message using both the reason code and the merchant's MCC. Certain RC 4853 Travel and Entertainment sub-categories require MCC to produce the correct message; without MCC based routing, all T&E sub-categories would return the same generic message.
  • Eligibility rules, RC 4837: No Cardholder Authorization. Decision table and subflow covering eligibility conditions for chargebacks where the cardholder did not authorise the transaction.
  • Eligibility rules, RC 4849: Questionable Merchant Activity. Decision table and subflow covering eligibility conditions for chargebacks arising from transactions with merchants flagged for questionable activity.
  • Eligibility rules, RC 4870: Chip Liability Shift. Decision table and subflow covering eligibility conditions for chargebacks under the chip liability shift rules, where a chip capable card was used at a non-chip terminal.
  • Eligibility rules, RC 4871: Chip Liability Shift, Lost/Stolen/Never Received. Decision table and subflow covering eligibility conditions for chip liability shift chargebacks specifically for lost, stolen, or never received cards.
  • Eligibility rules, RC 4850: Installment Billing Dispute, Participating Countries. New reason code and eligibility rules covering chargebacks for disputes arising from instalment billing arrangements in Mastercard participating countries.
  • Eligibility rules, RC 4854: Cardholder Dispute Not Elsewhere Classified, US Domestic. New reason code and eligibility rules covering US domestic disputes that do not fit any other Mastercard reason code category.
App: Financial Services Card Operations

Workspace

  • Mastercom API integration embedded in card dispute workspace. The embedded Mastercom v6 lifecycle subflows are connected to the Mastercard dispute management workspace, enabling agents to trigger chargeback, case filing, and arbitration actions directly from workspace tasks with live Mastercom API calls executed transparently.

↑ Back to top

Release: March 2026

App: Mastercard Spoke

Card Data Security

  • Mastercard Spoke CDS: Look up Case Documents Response Parser updated. The Look up Case Documents response parser was updated to route retrieved case document data through the Card Data Security (Skyflow) application, preventing PCI scoped card data from being stored in ServiceNow.
  • Mastercard Spoke CDS: Look up Chargeback Documents Response Parser updated. The Look up Chargeback Documents response parser was updated to route retrieved chargeback document data through Card Data Security.
App: Skyflow / Card Data Security Integration

Subflows

  • Skyflow integration: reusable document attachment subflow. A reusable subflow attaches documents to either the Skyflow vault or a sys_attachment record depending on whether the Card Data Security application is installed on the instance. This subflow is the foundational routing component for all Mastercard and Visa document attachment operations.
  • Skyflow integration: Mastercom Look up Case Documents subflow (tokenization aware). The Look up Case Documents subflow was updated to retrieve and attach case documents through the Skyflow backed integration.
  • Skyflow integration: Mastercom Look up Chargeback Documents subflow (tokenization aware). The Look up Chargeback Documents subflow was updated to retrieve and attach chargeback documents through the Skyflow backed integration.

Card Data Security

  • Skyflow integration: validate connection and confirm document tokenization. A validation step confirms that the Skyflow connection is active and that document tokenization is functioning correctly before documents are submitted to the Mastercom API.
  • Skyflow integration: end-to-end Skyflow ID retrieval. An implementation for retrieving the Skyflow vault reference ID for a stored document, enabling other subflows to attach Skyflow backed documents to dispute tasks without handling raw PCI data.
  • Skyflow integration: Seismic UIB component for inline document display. A new Seismic UIB component was added to dispute workspace pages, exposing Skyflow stored document content inline within the workspace. Document data is wired to Skyflow backed references, so agents view documents in the workspace without raw PCI data being exposed in ServiceNow.
App: FSO Integration with Mastercard

Document handling

  • FSO-Mastercard: backend document validation, file type and file size checks. Attached files are now validated against Mastercard's file type and size requirements before they are submitted. Non-compliant files are rejected with an alert before reaching the Mastercom API, preventing submission failures that would otherwise surface days later as Mastercard processing rejections.
  • FSO-Mastercard: document auto-ZIP and mixed input handling. Multiple attachments are automatically compressed into a ZIP file before Mastercom API submission, reducing the number of API calls required for multi document submissions. Requires the com.glide.hub.action_step.zip platform plugin to be active on the instance.
  • FSO-Mastercard: document handling logic applied across all Mastercard touchpoints. The new document validation and ZIP compression logic was applied to all Mastercard workflow touchpoints, ensuring consistent document submission behaviour regardless of which workflow step generates the submission.
  • FSO-Mastercard: Create a Zip Attachment from Uploaded Documents (new action). A new action compresses uploaded documents into a single ZIP attachment for Mastercom submission.

Subflows

  • FSO-Mastercard: Mastercom, Validate and Process Attachments of Card Disputes Task (new subflow). A new subflow centralises document validation and processing logic for all Mastercard dispute task document submissions.
  • FSO-Mastercard CDS: Look up Case Documents subflow updated. The Look up Case Documents subflow was updated to route document retrieval through the Card Data Security (Skyflow) application.
  • FSO-Mastercard CDS: Look up Chargeback Documents subflow updated. The Look up Chargeback Documents subflow was updated to route document retrieval through Card Data Security.
  • FSO-Mastercard CDS: Create Case Filing subflow updated. The Create Case Filing subflow was updated to route document handling through Card Data Security.
  • FSO-Mastercard CDS: Create Chargeback subflow updated. The Create Chargeback subflow was updated to route document handling through Card Data Security.
  • FSO-Mastercard CDS: Take Action on Case subflow updated. The Take Action on Case subflow was updated to route document handling through Card Data Security.
  • FSO-Mastercard CDS: Update Chargeback subflow updated. The Update Chargeback subflow was updated to route document handling through Card Data Security.
  • FSO-Mastercard: Load Data for Dispute Intake Adapter. When a Mastercard dispute flow is initiated, this adapter automatically calls Mastercom to retrieve authorization details and chargeback data and pre-populates the dispute intake context before the agent starts working the case. Agents no longer need to manually retrieve or enter this information at the start of an investigation.

Task management

  • FSO-Mastercard: SLAs for Mastercard dispute lifecycle tasks. Task level SLAs are now defined separately from case level SLAs for the Mastercard dispute lifecycle. Task SLAs operate independently and track time to resolution for individual chargeback lane tasks such as Review Chargeback, File Pre-Arbitration, and Review Arbitration Response.
App: Dispute Rules Content Pack for Mastercard

Chargeback eligibility rules

  • Eligibility rules, RC 4834 Cash not properly provided from Cash Back transaction. New eligibility rules were added covering the scenario where a cardholder requested cash back during a point of interaction transaction but the cash was not dispensed or was dispensed incorrectly.
  • Eligibility rules corrected, RC 4834 MCC 6011 condition for AcceptorCountryCode/Currency. A missing condition for MCC 6011 (ATM/cash dispensing) transactions in non-China AcceptorCountryCode combinations was added to the RC 4834 Transaction Amount Differs decision table. Agents now receive accurate eligibility guidance for this sub-category regardless of the transaction's country context.
  • RC 4834 dispute reason code label aligned with Mastercard API response. The RC 4834 dispute reason code label was aligned with the truncated label returned in the Mastercard API response, resolving a mismatch that could cause reason code display inconsistencies in the workspace.

↑ Back to top

Release: April 2026

App: Financial Services Operations Core

Platform configuration

  • CSM case type selector replaces FSO specific selector. FSO now uses the predefined CSM case type selector. Existing agent criteria and customer condition data are automatically migrated from deprecated FSO tables to CSM tables on upgrade, no manual migration is required. On upgraded instances, the deprecated FSO tables remain functional for backward compatibility but are no longer maintained.
  • FSO Core app scope changed from scoped administrative to non-scoped administrative. FSO Core is now a non-scoped administrative application. This change was completed as part of the Australia release and required prior engineering investigation to assess impact on existing customers.
  • Response code choices: Account Not Yet Activated and Closed Account added. Two previously missing response code values, Account Not Yet Activated and Closed Account, were added to dispute intake forms. These values are relevant for authorization dispute categorization.

↑ Back to top

Release: May 2026

App: Dispute Rules Content Pack for Mastercard

Data fields

  • 14 new data fields added to Financial Transaction and Authorization tables. Data fields: 14 new fields (not counted in the eligibility condition totals below). Fourteen new data fields were added to support the expanded Mastercard chargeback eligibility rules. Fields sourced from Mastercard's authorization API are added to the Financial Transaction Authorization table; fields sourced from the clearing API are added to the Financial Transaction table. transactionAmountLocal was extended from the Financial Transaction table to the Financial Transaction Authorization table.

Data model

  • Financial Transaction Authorization table: new table with workspace form view. A new table (sn_bom_financial_transaction_authorization) was introduced to store authorization level data for Mastercard dispute transactions. The table includes a workspace form view, allowing administrators to view authorization records directly from the associated financial transaction record.
  • Authorization Date and Time field now sourced from Core Banking Data. The Authorization Date and Time field used in Mastercard chargeback eligibility rule evaluation is now populated from Core Banking Data on the financial transaction record rather than being retrieved directly from the Mastercard API at evaluation time. Eligibility rules now evaluate against locally stored authorization data.

Questionnaire

  • New questionnaire question, RC 4808 (all sub-categories): Mandatory certification statement. Questionnaire: Authorization, New (1 of the category's 1 New). A mandatory certification statement was added to the dispute questionnaire for all RC 4808 sub-categories. The agent or cardholder must confirm that authorization was required but not properly obtained before an Authorization chargeback can proceed. This statement appears after the dispute amount modification reason field and creates an auditable confirmation for each Authorization chargeback.
  • New questionnaire question, RC 4853 Failed Travel Merchant: Bond/insurance scheme response. Questionnaire: Consumer Dispute, New (1 of the category's 2 New). A new questionnaire question was added for RC 4853 Failed Travel Merchant disputes involving a bond or insurance scheme, asking what response was received from the bonding authority. Applies to Intra-EEA and Domestic European transactions only.
  • New questionnaire question, RC 4853 Failed Travel Merchant: Date of reimbursement request submission. Questionnaire: Consumer Dispute, New (2 of the category's 2 New). A new questionnaire question was added for RC 4853 Failed Travel Merchant disputes where no response has been received from a bonding authority, asking for the date on which the reimbursement request was submitted.
  • Questionnaire, Consumer Dispute question conditions refined (RC 4853 Failed Travel Merchant and related). Questionnaire: Consumer Dispute, Refined (5 of the category's 5 Refined). Display conditions were updated on five existing Consumer Dispute questions (expected receipt date, original expected delivery/performance date, merchant bankruptcy/liquidation status, bond/insurance scheme, and supporting documentation) to extend coverage to the new RC 4853 Failed Travel Merchant sub-category and, for the supporting documentation question, to apply consistently across all dispute categories.
  • Questionnaire, Authorization question conditions refined (credit voucher and account status questions). Questionnaire: Authorization, Refined (4 of the category's 4 Refined). Display conditions were updated on four existing Authorization questions (account status as of transaction date, and the credit voucher/transaction receipt/refund acknowledgement question set) to correctly surface for the new RC 4808 Authorization sub-categories, and an erroneous hard stop error was removed for authorization reason codes.

Chargeback eligibility rules

  • Eligibility rules updated, RC 4808 RANO: Required Authorization Not Obtained. Conditions: 10 New, 0 Refined, 25 total (see the shared conditions below for the 15 also applied to ECPP, SIXCAID, CAT3D, and TFRR). Ten new ineligibility conditions were added for the RANO sub-category of RC 4808, covering:
    • Authorization already obtained online, via chip, Stand-In, or X-Code
    • US automated fuel dispenser transactions on Mastercard corporate cards, up to $500
    • US automated fuel dispenser transactions on other Mastercard cards, up to $175
    • US domestic card-not-present restaurant transactions, within a 30% gratuity tolerance
    • US domestic card-present transactions, within a 30% gratuity tolerance
    • Card-present transactions outside the US, within a 20% gratuity tolerance
    • Greece domestic installment transactions properly authorized within the approved amount
    • Mainland China domestic transactions disputed within the 5 to 90 day filing window
    • Europe ATM/Maestro domestic transactions disputed within the 120 day filing window
    • All other transactions disputed within the 90 day filing window
  • Eligibility rules updated, RC 4808 ECPP: Expired Chargeback Protection Period. Conditions: 11 New, 0 Refined, 26 total (shares the conditions listed below). One additional drafted condition, a refund timing rule, was withdrawn before release as a duplicate of the shared refund timing condition. Eleven new ineligibility conditions were added for the ECPP sub-category of RC 4808, covering:
    • Acquirer/merchant financed installment payments, transit debt recovery transactions, and non-Mastercard-BIN Maestro transactions
    • India domestic transactions: account in good standing, not a preauthorization, or presented within 4 days
    • Europe Maestro (non-ATM) domestic transactions: equivalent good standing/timing conditions
    • All other transactions: equivalent good standing/timing conditions, within 30 days
    • Costa Rica domestic transactions: account in good standing, or presented within 30 days
    • All other transactions: account in good standing, or presented within 7 days
    • Payment Transactions presented within 1 day of authorization approval
    • Contactless transit aggregated transactions presented within 14 days of authorization approval
    • Mainland China domestic transactions disputed within the 5 to 90 day filing window
    • Europe ATM/Maestro domestic transactions disputed within the 120 day filing window
    • All other transactions disputed within the 90 day filing window
  • Eligibility rules updated, RC 4808 SIXCAID: Stand-in or X-Code Approval after Issuer Decline. Conditions: 2 New, 0 Refined, 17 total (shares the conditions listed below). Two new eligibility conditions were added for the SIXCAID sub-category:
    • Card-present transactions, or card-not-present transactions initially declined then approved via Stand-In/X-Code for the same merchant, PAN, and expiration date (excluding Mainland China domestic and Maestro transactions)
    • All transactions disputed within the 90 day filing window
  • Eligibility rules updated, RC 4808 CAT3D: CAT 3 Device Transactions. Conditions: 6 New (2 refined before ship), 0 Refined, 23 total (shares the conditions listed below). Eight ineligibility conditions were added for the CAT3D sub-category, covering:
    • Transactions not classified as CAT 3
    • Transactions using an MCC other than 4784 (bridges/road tolls), 5499 (convenience stores, contactless only), 7523 (parking), or 7542 (car washes)
    • Mainland China domestic transactions
    • Transactions where the card's PAN was expired or not yet valid
    • Europe region transactions where the card wasn't encoded for positive online authorization
    • Magnetic stripe transactions
    • Transactions not identified with one of the listed MCCs
    • All transactions disputed within the 90 day filing window
  • Eligibility rules updated, RC 4808 TFRR: Transit First Ride Risk Framework. Conditions: 6 New, 0 Refined, 21 total (shares the conditions listed below). Six new eligibility conditions were added for the TFRR sub-category, covering:
    • Transactions that don't qualify as a transit first ride risk transaction
    • Mainland China domestic transactions (not currently supported for contactless transit)
    • Transactions approved on first attempt, or properly identified as contactless transit
    • Transactions the issuer declined with a "Not Claimable" response code
    • Transactions where the acquirer or merchant didn't meet Transit FRR/FRIL submission criteria
    • All transactions disputed within the 90 day filing window
  • Eligibility rules updated, RC 4808: shared conditions across RANO, ECPP, SIXCAID, CAT3D, and TFRR. Conditions: 15 New, 0 Refined, 15 total. Applied identically to all five sub-categories above; counted once here rather than once per sub-category. Fifteen new ineligibility conditions apply across the whole RC 4808 family, covering:
    • Authorization required but not obtained (including purchases, refunds, and cash back transactions)
    • Refunds presented in clearing within 5 days of the refund/authorization date
    • Accounts not in good standing at the time of dispute
    • Preauthorized transactions presented within 30 days of authorization
    • Costa Rica domestic: final authorization transactions presented within 30 days
    • India domestic: final authorization transactions presented within 4 days
    • All other transactions: final authorization transactions presented within 7 days
    • Undefined authorization transactions presented within 7 days
    • Card-present transactions, or card-not-present transactions declined then approved via Stand-In/X-Code with a "cannot approve, try later" code, or approved on the first attempt
    • Card-not-present transactions declined then subsequently approved through any channel other than Stand-In/X-Code
    • Transactions properly completed at a CAT 3 device (with limited exceptions)
    • Contactless transit aggregated transactions approved on first attempt, within the transit CVM limit
    • India domestic: contactless transit transactions presented within 4 days of the first tap
    • All other transit transactions presented within 14 days of the first tap
    • Taiwan domestic in-flight transactions
  • Eligibility rules updated, RC 4870: Chip Liability Shift expanded. Conditions: 10 New (2 refined before ship), 11 Refined, 21 total. Ten new ineligibility conditions were added for RC 4870, covering:
    • Transactions made with a Mastercard Biometric Card using successful biometric authentication
    • Transactions approved after two or more prior chargebacks on the same account for RC 4837, 4870, or 4871
    • Transactions on accounts exceeding 35 aggregate fraud related chargebacks (formula corrected before ship)
    • Intra-European and inter-European ATM technical fallback transactions, unless processed with a counterfeit card
    • Mainland China domestic transactions involving a counterfeit card at a hybrid POS or non-ATM terminal
    • Mainland China domestic transactions using a validly issued PBoC chip card
    • Mainland China domestic transactions reported to Risk Management as counterfeit
    • Transactions outside Mainland China involving a counterfeit card at a hybrid POS or non-ATM terminal
    • Transactions outside Mainland China using a validly issued EMV chip card
    • Transactions outside Mainland China reported as counterfeit to the Fraud and Loss Database within the required window (chargeback date calculation clarified with engineering before ship)
    Eleven existing conditions were also refined (wording and formula corrections, not new business logic), covering DSRP transactions, Consumer-Presented QR transactions, magnetic stripe/technical fallback transactions, non-EMV or counterfeit card transactions, mail/phone/e-commerce transactions, contactless transactions, Commercial Payments Account transactions, Brazil domestic Agro Card transactions, Mainland China domestic PBoC chip conditions, and Colombia domestic transactions.
  • Eligibility rules updated, RC 4871: Chip Liability Shift, Lost/Stolen/NRI expanded. Conditions: 8 New, 11 Refined, 19 total. Eight new ineligibility conditions were added for RC 4871, covering:
    • Counterfeit card transactions (directed instead to RC 4870)
    • Transactions approved after two or more prior chargebacks on the same account for RC 4837, 4870, or 4871
    • Transactions on accounts exceeding 35 aggregate fraud related chargebacks
    • ATM transactions (not permitted under this reason code)
    • Transactions made with a Mastercard Biometric Card using successful biometric authentication
    • Transactions where online PIN data was provided, including cash back
    • PIN enabled hybrid POS transactions approved through PIN bypass functionality
    • Hybrid terminal transactions where the PIN pad was missing or not working
    Eleven existing conditions were also refined (wording and formula corrections), covering DSRP transactions, Consumer-Presented QR transactions, magnetic stripe/technical fallback transactions, mail/phone/e-commerce transactions, Commercial Payments Account transactions, Colombia domestic transactions, Malaysia and other hybrid terminal PIN capability conditions, the 120 day filing window, fraud reporting window conditions, and hybrid PIN preferring card transactions at magnetic stripe only terminals.
  • Eligibility rules updated, RC 4837: No Cardholder Authorization expanded. Conditions: 2 New, 21 Refined, 23 total. Two new ineligibility conditions were added for RC 4837:
    • Intra-European and inter-European Maestro transactions completed with a signature at magnetic stripe only POS terminals
    • Purchase with cashback transactions, and standalone cash back transactions without an accompanying purchase
    Twenty-one existing conditions were also refined (wording and formula corrections, not new business logic), covering face to face card read transactions, France/Ireland/Turkey domestic Maestro CVC2 mismatches, Consumer-Presented QR transactions, CAT Level 1 and Level 3 transactions, account takeover transactions, authenticated e-commerce transactions, Commercial Payments Account transactions, low value digital goods purchases, Brazil domestic Agro Card transactions, Colombia domestic transactions, Taiwan domestic transit transactions, Corporate Purchasing Department Account transactions, and the Mainland China and international fraud reporting and filing window conditions.
  • Eligibility rules updated, RC 4849: Questionable Merchant Activity expanded. Conditions: 4 New, 0 Refined, 4 total. Four new ineligibility conditions were added for RC 4849, covering:
    • Coercion claims against the merchant that Mastercard did not substantiate
    • Transactions the issuer did not report to the Fraud and Loss Database within the required window
    • Mainland China domestic transactions not properly reported to Risk Management
    • Mainland China domestic disputes filed outside the 5 to 90 day window
  • RC 4853 Failed Travel Merchant geographic scoping enforced in decision table. Conditions: covered within the RC 4853 Failed Travel Merchant total below (14 total). The Intra-EEA and Domestic European transaction scope for the RC 4853 Failed Travel Merchant sub-category is enforced through transaction attribute conditions in the decision table itself, not as a separate questionnaire filter. The eligibility rules automatically apply or exclude this sub-category based on the transaction's origin.
  • Eligibility rules, RC 4853 Failed Travel Merchant: initial delivery. Conditions: 14 New (5 refined before ship), 0 Refined, 14 total. Fourteen eligibility conditions were delivered for the new RC 4853 Failed Travel Merchant, Intra-EEA and Domestic European Transactions Only sub-category, covering:
    • The travel merchant must have failed (bankruptcy, insolvency, or receivership) and be non-operational (documentation label corrected before ship)
    • Required supporting documentation: a cardholder statement and description of the purchased travel services
    • 150 day filing window from the latest expected service date, regardless of bonding authority response (timing formula corrected before ship)
    • Chargeback filed less than 30 days after the reimbursement request with no response yet received (timing formula corrected before ship)
    • No reimbursement claim submitted despite an applicable bond or insurance scheme (timing formula corrected before ship)
    • German domestic: 240 day filing window from the latest expected service date
    • German domestic: chargeback filed less than 60 days after the reimbursement request with no response
    • German domestic: no reimbursement claim submitted despite an applicable scheme
    • Polish domestic: 540 day filing window from the central site business date
    • Polish domestic: chargeback filed less than 60 days after the reimbursement request with no response
    • Polish domestic: no reimbursement claim submitted despite an applicable scheme
    • Swedish domestic: 120 day filing window from the latest expected service date
    • All other regions: 120 day filing window from the latest expected service date
    • An extended 365 day filing window for a defined list of travel related merchant category codes (timing formula corrected before ship)
  • Eligibility rules corrected, RC 4871 ineligibility reason message. Conditions: covered within the RC 4871 total above (Chip Liability Shift, Lost/Stolen/NRI, 19 total). The ineligibility reason message returned for Chip Liability Shift, Lost/Stolen/Never Received Issue (NRI) disputes (RC 4871) was incorrect and has been corrected to accurately describe the ineligibility condition.
  • Zurich eligibility rule changes released to Australia release track. Eligibility rule changes originally delivered on the Zurich release track (covering RC 4808, RC 4853 Failed Travel Merchant, Fraud sub-categories, and new data fields) were formally released to the Australia track, ensuring customers on either release track receive the same eligibility rule coverage.
App: FSO Integration with Mastercard

Defects and corrections

  • Mastercom: Look up Transaction Detail date format corrected. The Mastercom Look up Transaction Detail subflow was passing date values using the display format, which varies by regional locale settings. The subflow now passes dates in a fixed ISO format as required by the Mastercom API, preventing API failures for instances running non-default locale configurations.

↑ Back to top

Release: June 2026

App: FSO Integration with Mastercard

Subflows

  • Program Registration ID added to Mastercom Look up Clearing Transaction Details. The Program Registration ID field is now retrieved and mapped from Mastercom when the Look up Clearing Transaction Details subflow runs. This field is required for certain Mastercard chargeback eligibility conditions and was not previously captured in the FSO data model from clearing transaction data.
App: Financial Services Card Operations

Chargeback eligibility rules

  • Internal policy rules now evaluate against dispute amount. Policy rules in the Card dispute rules for internal policy decision table now evaluate against the dispute amount rather than the original transaction amount. Disputes where the cardholder modified the disputed amount during intake now flow through to policy rule evaluation correctly, ensuring accurate internal policy outcomes for partial amount disputes.

Workspace

  • Dispute intake: race condition in Review Intake step eliminated. The "Continue" activity action on the Review Intake task had a 2 to 3 second delay before hiding the Modify Transactions and Dispute Reason buttons. During this window, agents could make changes that caused data inconsistency. The Continue button has been replaced with a custom UIB component that hides all edit buttons immediately on click. Validation errors are displayed in a dismissible alert and re-enable editing for correction.
App: Financial Services Operations Core

Platform configuration

  • FSO Core changed to non-scoped administrative application. Financial Services Operations Core is now a non-scoped administrative application. Customers upgrading to the June 2026 release will receive this change automatically; no manual configuration is required.

↑ Back to top

Release: July 2026

App: Dispute Rules Content Pack for Mastercard

Chargeback eligibility rules

  • Eligibility rules, RC 4808 RANO: Required Authorization Not Obtained (expanded). Conditions: 2 New, 3 Refined, 2 Common-New, 1 Common-Refined, 8 total. Two new conditions were added specific to RANO:
    • US domestic Maestro card-not-present restaurant transactions (MCC 5812/5814), within the existing 30% gratuity tolerance
    • US domestic Maestro card-present transactions, within the existing 30% gratuity tolerance
    Three existing RANO conditions were also refined (the card-not-present and card-present gratuity tolerance conditions for non-Maestro cards, and the gratuity tolerance for transactions outside the US). RANO also receives 2 new and 1 refined condition shared across the whole RC 4808 family (see below).
  • Eligibility rules, RC 4808 ECPP: Expired Chargeback Protection Period (expanded). Conditions: 0 New, 0 Refined, 2 Common-New, 1 Common-Refined, 3 total. No conditions specific to ECPP were added this release. ECPP receives the 2 new and 1 refined condition shared across the RC 4808 family (see below).
  • Eligibility rules, RC 4808 SIXCAID: Stand-in or X-Code Approval after Issuer Decline (expanded). Conditions: 0 New, 0 Refined, 2 Common-New, 1 Common-Refined, 3 total. No conditions specific to SIXCAID were added this release. SIXCAID receives the 2 new and 1 refined condition shared across the RC 4808 family (see below).
  • Eligibility rules, RC 4808 CAT3D: CAT 3 Device Transactions (expanded). Conditions: 0 New, 0 Refined, 2 Common-New, 1 Common-Refined, 3 total. No conditions specific to CAT3D were added this release. CAT3D receives the 2 new and 1 refined condition shared across the RC 4808 family (see below).
  • Eligibility rules, RC 4808 TFRR: Transit First Ride Risk Framework (expanded). Conditions: 0 New, 0 Refined, 2 Common-New, 1 Common-Refined, 3 total. No conditions specific to TFRR were added this release. TFRR receives the 2 new and 1 refined condition shared across the RC 4808 family (see below).
  • Eligibility rules, RC 4808: shared conditions added across RANO, ECPP, SIXCAID, CAT3D, and TFRR. Conditions: 2 New, 1 Refined, 3 total. Applied identically to all five sub-categories above; counted once here rather than once per sub-category. Two new conditions apply across the whole RC 4808 family, covering UK domestic contactless transit split clearing transactions authorized for GBP 0.10 (two related scenarios distinguished by merchant type code). The existing "account not in good standing" condition was also refined.
  • Eligibility rules, RC 4854: Cardholder Dispute Not Elsewhere Classified, US Domestic (expanded). Conditions: 6 New, 0 Refined, 0 Common-New, 0 Common-Refined, 6 total. Six new conditions were added for RC 4854, covering:
    • The reason code is only valid for US domestic transactions
    • Required supporting documentation from the cardholder
    • 60 day filing window from when the cardholder first notified the issuer (two related conditions covering the wait period after returned merchandise)
    • 120 day filing window from the transaction's central site business date (two related conditions covering the wait period after returned merchandise)
  • Eligibility rules, RC 4853 GOSWEN: Goods or Services Not as Described (expanded). Conditions: 0 New, 1 Refined, 4 Common-New, 0 Common-Refined, 5 total. The supporting documentation condition for GOSWEN was refined (added guidance for claims about quality or misrepresentation). GOSWEN also receives 4 new conditions shared across the RC 4853 family (see below).
  • Eligibility rules, RC 4853 GOS: Goods or Services Not Provided (expanded). Conditions: 2 New, 0 Refined, 4 Common-New, 0 Common-Refined, 6 total. Two new conditions were added for GOS:
    • The chargeback doesn't apply if the cardholder signed a waiver absolving the merchant of responsibility for undelivered merchandise
    • Netherlands domestic Maestro face to face POS transactions are excluded
    GOS also receives 4 new conditions shared across the RC 4853 family (see below).
  • Eligibility rules, RC 4853 TESNR: Travel/Entertainment Services Not Provided (expanded). Conditions: 1 New, 0 Refined, 4 Common-New, 0 Common-Refined, 5 total. One new condition was added for TESNR, excluding Intra-EEA and domestic European failed travel merchant disputes (those route to the Failed Travel Merchant sub-category instead). TESNR also receives 4 new conditions shared across the RC 4853 family (see below).
  • Eligibility rules, RC 4853 DGP: Digital Goods Purchase (expanded). Conditions: 2 New, 0 Refined, 4 Common-New, 0 Common-Refined, 6 total. Two new conditions were added for DGP: a clarified definition of digital goods (excluding gift cards), and an exclusion for interregional Maestro transactions. DGP also receives 4 new conditions shared across the RC 4853 family (see below).
  • Eligibility rules, RC 4853 RNP: Refund Not Processed (expanded). Conditions: 4 New, 0 Refined, 4 Common-New, 0 Common-Refined, 8 total. Four new conditions were added for RNP:
    • Required supporting documentation from the cardholder
    • An exclusion for a defined list of travel related MCCs where the merchant properly disclosed a voucher for future use policy
    • Mainland China domestic: 90 day filing window from the credit documentation date
    • Intra/inter-European Maestro transactions: 30 to 120 day filing window from the return or cancellation date
    A logic correction was also applied: the MCC condition for the 3000 to 3999 range is now evaluated with OR rather than AND against the additional MCC list. RNP also receives 4 new conditions shared across the RC 4853 family (see below).
  • Eligibility rules, RC 4853 CG: Counterfeit Goods (expanded). Conditions: 1 New, 0 Refined, 4 Common-New, 0 Common-Refined, 5 total. One new condition excludes Maestro transactions from the CG reason code. CG also receives 4 new conditions shared across the RC 4853 family (see below).
  • Eligibility rules, RC 4853 CDORT: Cardholder Dispute of Recurring Transaction (expanded). Conditions: 1 New, 1 Refined, 4 Common-New, 0 Common-Refined, 6 total. One new condition confirms the disputed transaction must be recurring, not an installment billing arrangement. The supporting documentation condition was also refined. CDORT also receives 4 new conditions shared across the RC 4853 family (see below).
  • Eligibility rules, RC 4853 IDORT: Issuer Dispute of Recurring Transaction (expanded). Conditions: 1 New, 0 Refined, 4 Common-New, 0 Common-Refined, 5 total. One new condition confirms the disputed transaction must be recurring, not an installment billing arrangement. IDORT also receives 4 new conditions shared across the RC 4853 family (see below).
  • Eligibility rules, RC 4853 ADD: Addendum Dispute (expanded). Conditions: 1 New, 1 Refined, 4 Common-New, 0 Common-Refined, 6 total. One new condition excludes Maestro transactions from the ADD reason code. The supporting documentation condition was also refined. ADD also receives 4 new conditions shared across the RC 4853 family (see below).
  • Eligibility rules, RC 4853 TDNC: Transaction Did Not Complete (expanded). Conditions: 2 New, 2 Refined, 4 Common-New, 0 Common-Refined, 8 total. Two new conditions were added: an exclusion for Maestro transactions, and a 10 business day filing window for Costa Rica domestic transactions. The supporting documentation condition and the general 120 day filing window were also refined. TDNC also receives 4 new conditions shared across the RC 4853 family (see below).
  • Eligibility rules, RC 4853 NOSHC: No-Show Hotel Charge (expanded). Conditions: 2 New, 0 Refined, 4 Common-New, 0 Common-Refined, 6 total. Two new conditions were added for NOSHC: the reason code only applies to charges from hotel merchants, and Maestro transactions are excluded. NOSHC also receives 4 new conditions shared across the RC 4853 family (see below).
  • Eligibility rules, RC 4853 Timeshares (expanded). Conditions: 1 New, 2 Refined, 4 Common-New, 0 Common-Refined, 7 total. One new condition sets a 15 to 120 day filing window for Intra/inter-European Maestro transactions. The supporting documentation condition and the general 120 day filing window were also refined; the input field label used in cardholder notified issuer date conditions was renamed for clarity. Timeshares also receives 4 new conditions shared across the RC 4853 family (see below).
  • Eligibility rules, RC 4853 RPAP: Refund Posted as Purchase (expanded). Conditions: 0 New, 2 Refined, 4 Common-New, 0 Common-Refined, 6 total. The general 120 day filing window was refined, and a note was added clarifying the chargeback amount can be up to twice the original transaction amount to offset the posting error. RPAP also receives 4 new conditions shared across the RC 4853 family (see below).
  • Eligibility rules, shared conditions added across all 13 RC 4853 sub-categories. Conditions: 4 New, 0 Refined, 4 total. Applied identically across GOSWEN, GOS, TESNR, DGP, RNP, CG, CDORT, IDORT, ADD, TDNC, NOSHC, Timeshares, and RPAP; counted once here rather than once per sub-category. Four new conditions apply across the whole RC 4853 family (except RC 4854, which doesn't receive them):
    • Automated fuel dispenser transactions (MCC 5542) processed outside Europe are excluded
    • Transactions for goods or services processed as a cash disbursement are excluded
    • Brazil domestic transactions with MCC 9211 (court costs, including alimony and child support) are excluded
    • Business Payment Service Provider transactions are excluded, unless the cardholder claims improper posting or a missed refund
  • Eligibility rules, RC 4834 TAD: Transaction Amount Differs (expanded). Conditions: 0 New, 1 Refined, 1 total. The supporting documentation condition for TAD was refined, clarifying documentation requirements for Maestro transactions at non-European terminals and for Brazil domestic gratuity disputes.
  • Eligibility rules, RC 4834 CE: Currency Errors (expanded). Conditions: 1 New, 1 Refined, 2 total. One new condition excludes ATM transactions unless both the card and the ATM are issued/located in Europe. The condition describing an incorrect currency transaction was also refined.
  • Eligibility rules, RC 4834 MRCERICCEXL: Merchant Refund Correcting Error Resulting in Currency Exchange Loss (expanded). Conditions: 0 New, 3 Refined, 3 total. Three existing conditions were refined: the chargeback amount is limited to the currency exchange loss portion (not the full transaction), Mainland China domestic transactions are excluded, and ATM transactions are excluded.
  • Eligibility rules, Acceptor country code condition corrected across all 13 RC 4853 sub-categories. Not separately counted, this describes the shared MCC 5542 Common condition already included in each sub-category's Common-New count above. A condition used across all thirteen RC 4853 sub-categories (GOSWEN, GOS, TESNR, DGP, RNP, CG, CDORT, IDORT, ADD, TDNC, NOSHC, Timeshares, and RPAP) evaluated the MCC 5542 (automated fuel dispensers) acceptor country code exclusion using a single NOT IN operator with a comma separated list. This operator evaluates incorrectly for string fields on the ServiceNow platform. All thirteen conditions have been corrected to use 71 individual != conditions per country code, matching the already correct pattern used by RC 4854 rules.
App: Financial Services Card Operations

Questionnaire

  • New questionnaire field: Waiver or insurance status for merchandise delivery (RC 4853 GOS). Questionnaire: Cardholder Disputes, New (1 of the category's 1 New). A new waiver_insurance_status field was added to the dispute intake questionnaire for Mastercard Goods or Services Not Provided disputes. The field captures whether a liability waiver was signed, insurance was declined, both apply, or neither applies to the merchandise delivery situation. This field is mandatory for agents and optional for cardholders when the dispute reason meets the applicable condition.
  • Questionnaire field modified: Price/amount discrepancy indicator (RC 4834 Transaction Amount Differs). Questionnaire: Cardholder Disputes, Refined. The display conditions for the merchant_dispute_price_diff_ind field were updated. The field, present on the cardholder dispute intake form since 2024, asks whether the dispute is due to a difference between the quoted price and the merchant's actual charge, and now surfaces when the cardholder selects Transaction Amount Differs (Mastercard) or Incorrect Amount (Visa) as the issue and has provided a receipt amount.
  • New questionnaire values: Account Status choices for Mastercard Authorization disputes. Questionnaire: Authorization, New (1 of the category's 1 New). Five new account status values were added for Mastercard Authorization category disputes, available to agents completing authorization related chargebacks:
    • AC, Account closed
    • SOR, Suspended or restricted (legal hold, deceased, dormant, frozen, under investigation, non-credit)
    • FOC, Fraud or compromise (confirmed fraud, suspected fraud, account compromise, identity theft flag)
    • CRI, Credit related issue (delinquent, over limit, payment default, or non-payment restriction)
    • ACG, Account active and in good standing
    These values appear only in the Mastercard Authorization view and are mandatory for agents when the applicable dispute conditions are met.
  • Questionnaire, Dispute reason label updates and Multiple Authorization Request removed. Questionnaire: Cardholder Disputes, Refined. The dispute_due_to_mc choice list was updated with clearer display labels for CAT 3 Devices, Transit First Ride Risk (FRR) Framework Claims, Installment Billing Dispute, Participating Countries, and Cardholder Dispute Not Elsewhere Classified, US Domestic. Multiple Authorization Request was removed as a selectable dispute reason. These changes are reflected across the dictionary, choice list, and all related UI policies.
  • Questionnaire, Consumer Dispute conditions extended to cover US Domestic scenario. Questionnaire: Cardholder Disputes, Refined (covers the display condition updates to merchandise_or_services, cardholder_return_merchandise_ind, and cardholder_returned_merchandise_date). Conditions on three existing Consumer Dispute fields were updated to also apply when the dispute reason is Cardholder Dispute Not Elsewhere Classified, US Domestic, ensuring agents and cardholders see the correct fields for this scenario.
  • Questionnaire, "Late presentment" option removed (RC 4834). Questionnaire: Processing Errors, Refined (1 of the category's 1 Refined). The "Late presentment" option was removed from the Processing Errors intake question ("What is incorrect about this transaction?"), aligning the choice list with the RC 4834 reason code scope.

Data fields

  • New data fields: Program Registration ID added to Financial Transaction table. Data field (not a rule condition; counted separately from the 140 condition total). The programRegistrationId field was added to the Financial Transaction table, sourced from Mastercard clearing data. It supports the shared RC 4853 condition that evaluates MCC 7399 or a Program Registration ID of P11. This is the only new data field of this kind delivered in this release.

Defects and corrections

  • Dispute amount validation: floating-point comparison corrected. Code defect fix, not a rule or questionnaire condition; excluded from the 140 condition total. A floating point precision defect in the dispute amount validation logic was corrected. When comparing whether a dispute amount exceeds the transaction/receipt difference, JavaScript's floating point arithmetic could produce results like 26.479999999999997 instead of 26.48, causing valid dispute amounts that exactly equalled the allowed difference to be incorrectly rejected. The validation now rounds both values to four decimal places before comparison, eliminating false positives for exact boundary amounts.

↑ Back to top

What's Next

Related FSO Disputes articles for additional context:

Get Involved:

Happy implementing! Comment below for questions, additional assets, or to share your FSO success stories.

0 Helpfuls
  • 47 Views
Version history
Last update:
2 hours ago
Updated by:
ServiceNow Employee