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

## FAQ {#faq}

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. A fraud in FLD can be of the two types:

* **Confirmed fraud**: A transaction which is reported by a cardholder or identified by an Issuer and established as a fraudulent one. Only an Issuer or its processor can report such a 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.

* Suspect Fraud Add -- (SFA)
* Suspect Fraud Change -- (SFC)
* Suspected Fraud to Confirm - (FSC)
* Suspected Fraud to Not Confirm - (FSN)
* Suspected Fraud Delete - (SFD)
* Suspected Fraud Status - (SFS)

Note: Only Acquirer can delete the suspected fraud transactions. When an Issuer submits a suspected fraud record, FLD tries to match it against a transaction which is already present in Mastercard systems. If a successful match is found, FLD builds the suspected fraud record based on the information Mastercard already has. This is termed as a Mastercard-built fraud record. 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. No. The FLD APIs are designed to support only one record per request to ensure real-time processing of fraudulent transactions. Every request and response message will be linked through a Reference ID (refId), which is a unique 36-character value generated by the transaction initiator using UUID logic. This value is echoed back by FLD application in the response message. The Reference ID is always unique for a particular initiator and service combination.

1. Issuer A initiates SFA request using Reference ID as R1 -- Request is processed successfully.
2. Issuer A again initiates SFA request using Reference ID as R1 -- Request is not processed.
3. Issuer A initiates SFC request using Reference ID as R1 -- Request is processed successfully.
4. Issuer B now initiates SFC request using Reference ID as R1 -- Request is processed successfully.
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). This is used as a reference in the request API to subsequently modify (FDC), delete (FDD) or convert a suspended (FDE) record. This value will not be generated if the FDA request is not processed by FLD application. Mastercard's Customer Implementation Service (CIS) team will help you through the onboarding process for each environment. Once the connectivity is established successfully, you can start using the APIs. There are two environments where you need to get on-boarded.

* Sandbox or Mastercard Test Facility (MTF) is used for all the tests and pre-production validations.
* Production is used for commercial deployments.
FLD follows ISO 8583 standards for country and currency codes, which are updated as needed. For more information, refer to the current list of ISO Country and Currency Codes in [Annexure 3](https://developer.mastercard.com/fld-suspected-fraud/documentation/parameters/annexure-3/index.md). Yes, that is possible either way. There are no usage fees applicable when using FLD APIs. There may be CIS Implementation fees for the mandatory testing project, please confirm with your CIS Implementation manager.

## Get Help {#get-help}

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