# Support
source: https://developer.mastercard.com/fld-fraud-submission/documentation/support/index.md

## FAQ {#faq}

### General {#general}

The Fraud and Loss Database (FLD) is Mastercard's repository for fraudulent transactions, helping detect at-risk accounts and at-risk entities. This helps Mastercard develop fraud prevention programs, fraud trends and insights for all stakeholders.

For full scope and capabilities, see the [Overview](https://developer.mastercard.com/fld-fraud-submission/documentation/index.md).
A fraud in FLD can be of two types:

* **Confirmed fraud**: An Issuer or its processor reports a transaction as fraudulent when a cardholder identifies it or the Issuer confirms it as fraud.
* **Suspected fraud**: An Issuer or Acquirer has a strong suspicion of fraud, but it cannot establish with certainty at that point in time. Issuer, Acquirer or its respective processor can report such a fraud.


An entity has the ability to perform the following operations in FLD.

* Add a new fraud record -- FDA (Fraud Data Add)
* Change an existing fraud record -- FDC (Fraud Data Change)
* Delete an existing fraud record -- FDD (Fraud Data Delete)
* Confirm a suspended record -- FDE (Fraud Data Confirm)
When an Issuer submits a fraud record, FLD tries to match it against a transaction which is already present in Mastercard systems. If it finds a successful match, FLD uses the information already available with Mastercard to build the fraud record. Mastercard defines this as a Mastercard-built fraud record. If FLD does not find a match, it still builds the fraud record using the information the Issuer provides. Mastercard classifies this as an Issuer-built fraud record.

<br />

The goal of FLD APIs is to support all FLD operations across confirmed and suspected frauds, which will happen in a staggered manner. However, the current scope is confined to all FLD operations related to confirmed frauds by Issuers or their processors for both Mastercard and Issuer-built APIs.

### Onboarding {#onboarding}

Mastercard supports you through the onboarding process for each environment. Once the connectivity is established successfully, you can start using the APIs. For assistance, raise a case through [Mastercard Developers Support](https://developer.mastercard.com/support). There are two environments where you need to get on-boarded.

* Sandbox is used for all the tests and pre-production validations. Confirmed Fraud (FLD) does not have a separate Mastercard Test Facility (MTF) environment.
* Production is used for commercial deployments.

### Integration {#integration}

The Audit Control Number (auditControlNumber) is a unique number generated by FLD application and provided in the response message for a successful fraud record submission (FDA). The request API uses this value as a reference to modify (FDC), delete (FDD), or convert a suspended (FDE) record. The FLD application does not generate this value if it does not process the FDA request. FLD applies ISO 8583 standards for country and currency codes and updates them as needed. For more information, refer to the current list of ISO Country and Currency Codes in [Annexure 3](https://developer.mastercard.com/fld-fraud-submission/documentation/parameters/annexure-3/index.md). Yes, you must encrypt API data for Fraud Data Add (Complete and Minimal) and change APIs.

### Policy {#policy}

In the Production environment, you can subscribe to either minimal or complete FDA / FDC APIs according to your business need. However, it is advisable to test out all the APIs in the Sandbox environment to avoid any major development or rework at your end. Yes, that is possible, but there are exceptions.

* Operations on SMTM records can only be performed using the SMTM application.
* You can use FLD APIs to modify fraud records created in Mastercom Claim Manager, but not the other way around.
Mastercard recommends subscribing to all endpoints, but you can subscribe to specific endpoints according to your needs.

### Performance {#performance}

No. The FLD APIs are designed to support only one record per request to ensure real-time processing of fraudulent transactions. The transaction initiator generates a unique 36-character Reference ID (refId) using UUID logic and links every request and response message through it. The FLD application echoes this value in the response message. The Reference ID is always unique for a particular initiator and service combination.

1. Issuer A initiates FDA request using Reference ID as R1 -- Request is processed successfully.
2. Issuer A again initiates FDA request using Reference ID as R1 -- Request is not processed.
3. Issuer A initiates FDC request using Reference ID as R1 -- Request is processed successfully.
4. Issuer B now initiates FDA request using Reference ID as R1 -- Request is processed successfully.

### Troubleshooting {#troubleshooting}

FLD links every request and response through a unique 36-character **Reference ID (`refId`)**, and reusing an ID for the same initiator and service combination causes the request to be rejected.

**Likely causes**

* The same `refId` was reused for the same initiator and service.
* The `refId` was not generated using UUID logic, causing collisions.

**Steps to resolve**

1. Generate a fresh 36-character `refId` using UUID logic for each new request.
2. Ensure the `refId` is unique per initiator and service combination.
3. Retry the request with the new `refId`.

For more details, see the **Performance** FAQ above on linking request and response messages.
When you submit a fraud record, FLD validates it against the Mastercard transaction Data Warehouse (DWH) and existing fraud records, so a rejection or suspension usually points to a match problem rather than a malformed request.

**Likely causes**

* **41200 -- Unable to match transaction in data warehouse:** the minimal (Mastercard-built) request could not be matched to a transaction in the DWH.
* **30100 -- Potential Duplicate Data Found:** the transaction is already present as a confirmed-success fraud record, so the new record is suspended as a potential duplicate.

**Steps to resolve**

1. For **41200** , resubmit using the complete endpoint `POST /issuer-frauds`, which accepts full transaction details and submits an Issuer-built record when no DWH match is found.
2. For **30100** , review the `duplicateAuditControlNumbers` returned in the response. If the existing record is correct, no action is needed; otherwise delete (FDD) or confirm (FDE) the existing record through `PUT /fraud-states`.
3. Re-check the response `responseCode` and `errorDetails` after resubmitting.

For the full list of codes and resolutions, see [Code and Formats](https://developer.mastercard.com/fld-fraud-submission/documentation/code-and-formats/index.md).
Reason code **60018 -- Request initiator is not authorized for this particular account range** means your ICA is not provisioned for the BIN/account range in the request, so FLD blocks the operation.

**Likely causes**

* Your organization has not been provisioned for the ICA or account range in MC Connect.
* The submission uses an ICA or card range outside your provisioned scope.

**Steps to resolve**

1. Confirm the `icaNumber` and card range in your request are within your provisioned scope.
2. Request provisioning for the required account range through MC Connect --- see the [MC Connect Onboarding Guide](https://developer.mastercard.com/fld-fraud-submission/documentation/getting-onboarded-on-mc-connect/index.md).
3. Retry the request once provisioning is confirmed.

For the full list of codes and resolutions, see [Code and Formats](https://developer.mastercard.com/fld-fraud-submission/documentation/code-and-formats/index.md).

### Support {#support}

In the event that your team experiences issues, raise a case through [Mastercard Developers Support](https://developer.mastercard.com/support), and outline the following:

1. Email Subject: Confirmed Fraud API: Issue with (Describe Issue Here).
2. Body: Include details about the nature of the request, along with screenshots if possible to help expedite the resolution.
[The API Status Page](https://developer.mastercard.com/api-status) informs Mastercard Developers users of the status of each API.

## Get Help {#get-help}

### Contact us for technical support. {#contact-us-for-technical-support}