Skip to main content
Version: 1.1

Fraudio Data Schema

info

Here is Fraudio's full data schema, containing all of the data fields that we use, along with other useful information such as data type, priority level (by product), field description, and the API Endpoint that uses that field.

The schema is organised by API endpoint, which enables you to quickly locate all relevant fields associated with each endpoint.

User guide

First, select the Fraudio product you're using:

  • Payment Fraud Detection (for issuers)
  • Payment Fraud Detection (for acquirers or payment processors)
  • Merchant-Initiated Fraud Detection, or AML (Anti Money Laundering)

Filtering results

You can then optionally:

  • Filter by API endpoint to show only the fields which relate to that endpoint
  • Filter data fields by priority level
  • Use the search bar to quickly find the information you need
  • Sort by any column you'd like

Data Schema

Select Fraudio product:
Select an API endpoint group...
Select data fields by priority level:
API EndpointFieldData TypePayment Fraud (Acquirer / Processor)Description
Payment Fraud ScoretransactionidStringCritical & Required
The unique identifier of the transaction event. Every transaction event, so auth, capture, auth_capture, etc., has its own unique ID.
Payment Fraud ScoretransactiontypeStringCritical & Required
The type of transaction event, for events that need to be scored.

Accepted values are:
- auth: An authorization is used to reserve funds on the customer's card without yet deducting them.
- auth_capture: A simultaneous combination of auth and capture in the same transaction, for when there is no need to perform these operations separately.
Payment Fraud ScoretimestampDoubleCritical & Required
The UTC time at which the transaction was made. When sending events in realtime, this will usually be 'now'. Only Unix Timestamps are accepted.
Payment Fraud ScoreamountDoubleCritical & Required
The transaction amount in the unit specified by the 'currencyunit' field. Note: The unit used in this field should be explicitly stated in the 'currencyunit' field.
Payment Fraud ScorecurrencyStringCritical & Required
The 3-digit ISO code for the currency used in the transaction.
Payment Fraud ScorecurrencyunitStringCritical & Required
This field defines the unit of currency used in the 'amount' field. Accepts only major (e.g., 12.30) or minor (e.g., 1230) unit values. This choice should align with the unit used in the 'amount' field.
Payment Fraud ScorechannelStringCritical & Required
Indicates the specific type of channel used for a transaction.

Accepted values with their description:
- ecom: Ecommerce transaction, this is a card-not-present transaction done over the internet.
- pos: Point of Sale transaction, also known as card-present.
- moto: A mail or telephone order is a card-not-present transaction where the cardholder gives permission to process the transaction by providing order and payment details by mail (not email), fax, or telephone.
- atm: Automated Teller Machine transaction, where a card is used at an ATM for activities such as cash withdrawals and deposits.
Payment Fraud ScoremerchantStringCritical & Required
The identifier of the merchant. This field uniquely identifies the merchant, and should not be confused with the MID. Any unique identifier is accepted.
Payment Fraud ScoremcccodeStringCritical & Required
A Merchant Category Code (MCC) is a four-digit number listed for financial services. An MCC is used to classify a business by the types of goods or services it provides. Only ISO 18245 mcc codes are accepted.
Payment Fraud ScorecardbinStringCritical & Required
The Bank Identification Number (BIN), also known as the Issuer Identification Number (IIN), is the first six or eight digits of the card number.
Payment Fraud ScorelastfourdigitsStringCritical & Required
The last four digits of the card number.
Payment Fraud ScorecardexpirydateStringCritical & Required
The expiry date of the card. Accepted format: MM/yy.
Payment Fraud ScorecardtokenStringCritical & Required
The card token is the encryption that is used to identify the credit card. Any salted hash is accepted.
Payment Fraud ScoreresponsecodeStringCritical & Required
The response code is a numerical code that indicates the outcome of authorization checks of issuing banks. The code must be a 2 character ISO8583-1987 response.
Payment Fraud ScoresuccessStringCritical & Required
This indicates the overall result of the transaction.

Accepted values are:
- true: Transaction fully completed without any failures (both technical and non-technical).
- false: Any part of the transaction failed or did not meet the necessary criteria, regardless of technical success.
- none: The outcome of the transaction is uncertain or not yet known.
Please use true only for fully successful transactions. Use false if there's any doubt or known issues, and none when outcome information is incomplete.
Payment Events EnrichmenttransactionidStringCritical & Required
The unique identifier of the transaction event. Every transaction event, so auth, capture, auth_capture, etc., has its own unique ID.
Payment Events EnrichmenttransactiontypeStringCritical & Required
The type of transaction event, for events that do not need scoring.

Accepted values are:
- auth: An authorization is used to reserve funds on the customer's card without yet deducting them.
- capture: A capture is used to immediately deduct authorised funds (up to the amount auth'd) from a customer's card. A capture should always be linked to at least one authorization via the parenttransactionid.
- auth_capture: A simultaneous combination of auth and capture in the same transaction, for when there is no need to perform these operations separately.
- refund: A refund transaction returns credit to a customer's payment method.
- void: A void transaction is the explicit discarding of authorization of funds.
- top_up: Increases the available credit of a credit card.
- incremental_auth: A transaction that increases the authorised amount of a confirmed auth transaction that has not yet been captured.
- reversal: A reversal cancels the transaction and re-credits the customer's payment method. This happens directly after the transaction has taken place but before the funds have been fully processed.
- withdrawal: The withdrawal of cash from the cardholder's bank account.
- deposit: The deposit of cash into the cardholder's bank account.
- none: Use only when the transactiontype is unknown.
Payment Events EnrichmenttimestampDoubleCritical & Required
The UTC time at which the transaction was made. When sending events in realtime, this will usually be 'now'. Only Unix Timestamps are accepted.
Payment Events EnrichmentamountDoubleCritical & Required
The transaction amount in the unit specified by the 'currencyunit' field. Note: The unit used in this field should be explicitly stated in the 'currencyunit' field.
Payment Events EnrichmentcurrencyStringCritical & Required
The 3-digit ISO code for the currency used in the transaction.
Payment Events EnrichmentcurrencyunitStringCritical & Required
This field defines the unit of currency used in the 'amount' field. Accepts only major (e.g., 12.30) or minor (e.g., 1230) unit values. This choice should align with the unit used in the 'amount' field.
Payment Events EnrichmentchannelStringCritical & Required
Indicates the specific type of channel used for a transaction.

Accepted values with their description:
- ecom: Ecommerce transaction, this is a card-not-present transaction done over the internet.
- pos: Point of Sale transaction, also known as card-present.
- moto: A mail or telephone order is a card-not-present transaction where the cardholder gives permission to process the transaction by providing order and payment details by mail (not email), fax, or telephone.
- atm: Automated Teller Machine transaction, where a card is used at an ATM for activities such as cash withdrawals and deposits.
Payment Events EnrichmentmerchantStringCritical & Required
The identifier of the merchant. This field uniquely identifies the merchant, and should not be confused with the MID. Any unique identifier is accepted.
Payment Events EnrichmentmcccodeStringCritical & Required
A Merchant Category Code (MCC) is a four-digit number listed for financial services. An MCC is used to classify a business by the types of goods or services it provides. Only ISO 18245 mcc codes are accepted.
Payment Events EnrichmentcardbinStringCritical & Required
The Bank Identification Number (BIN), also known as the Issuer Identification Number (IIN), is the first six or eight digits of the card number.
Payment Events EnrichmentlastfourdigitsStringCritical & Required
The last four digits of the card number.
Payment Events EnrichmentcardexpirydateStringCritical & Required
The expiry date of the card. Accepted format: MM/yy.
Payment Events EnrichmentcardtokenStringCritical & Required
The card token is the encryption that is used to identify the credit card. Any salted hash is accepted.
Payment Events EnrichmentresponsecodeStringCritical & Required
The response code is a numerical code that indicates the outcome of authorization checks of issuing banks. The code must be a 2 character ISO8583-1987 response.
Payment Events EnrichmentsuccessStringCritical & Required
This indicates the overall result of the transaction.

Accepted values are:
- true: Transaction fully completed without any failures (both technical and non-technical).
- false: Any part of the transaction failed or did not meet the necessary criteria, regardless of technical success.
- none: The outcome of the transaction is uncertain or not yet known.
Please use true only for fully successful transactions. Use false if there's any doubt or known issues, and none when outcome information is incomplete.
Payment Post-Authorization EnrichmenttransactionidStringCritical & Required
The unique identifier of the transaction event. Every transaction event, so auth, capture, auth_capture, etc., has its own unique ID.
Payment Post-Authorization EnrichmenttimestampDoubleCritical & Required
The UTC time at which the transaction was made. When sending events in realtime, this will usually be 'now'. Only Unix Timestamps are accepted.
Payment Post-Authorization EnrichmenttransactiontypeStringCritical & Required
The type of transaction event.

Accepted values are:
- auth: An authorization is used to reserve funds on the customer's card without yet deducting them.
- capture: A capture is used to immediately deduct authorised funds (up to the amount auth'd) from a customer's card. A capture should always be linked to at least one authorization via the parenttransactionid.
- auth_capture: A simultaneous combination of auth and capture in the same transaction, for when there is no need to perform these operations separately.
- refund: A refund transaction returns credit to a customer's payment method.
- void: A void transaction is the explicit discarding of authorization of funds.
- top_up: Increases the available credit of a credit card.
- incremental_auth: A transaction that increases the authorised amount of a confirmed auth transaction that has not yet been captured.
- reversal: A reversal cancels the transaction and re-credits the customer's payment method. This happens directly after the transaction has taken place but before the funds have been fully processed.
- none: Use only when the transactiontype is unknown.
Payment Post-Authorization EnrichmentsuccessStringCritical & Required
This indicates the overall result of the transaction.

Accepted values are:
- true: Transaction fully completed without any failures (both technical and non-technical).
- false: Any part of the transaction failed or did not meet the necessary criteria, regardless of technical success.
- none: The outcome of the transaction is uncertain or not yet known.
Please use true only for fully successful transactions. Use false if there's any doubt or known issues, and none when outcome information is incomplete.
Payment Post-Authorization EnrichmentresponsecodeStringCritical & Required
The response code is a numerical code that indicates the outcome of authorization checks of issuing banks. The code must be a 2 character ISO8583-1987 response.
Dispute EventstransactionidStringCritical & Required
The unique identifier of the transaction event. Every transaction event, so auth, capture, auth_capture, etc., has its own unique ID.
Dispute EventstimestampDoubleCritical & Required
The UTC time at which the transaction was made. When sending events in realtime, this will usually be 'now'. Only Unix Timestamps are accepted.
Dispute EventsreporttypeStringCritical & Required
The type of fraud report. Please note: 1st chargebacks and fraud notifications are the priority here, especially during integration!

Accepted values are:
- fraud notification: Fraud activity reported by the (cardholder's) bank. Examples are Visa's TC40 files and MasterCard's SAFE files.
- 1st chargeback: First stage of the chargeback where the disputed amount is withdrawn from the merchant's account.
- information supplied: Defense documents against the 1st chargeback are supplied.
- chargeback reversal: The disputed amount is transferred back to the merchant's account.
- pre-arbitration: A stage in a chargeback dispute where the issuer, unconvinced with the merchant's provided evidence, escalates the case for further review, serving as an intermediate step before potential full arbitration.
- 2nd chargeback: 2nd and definite chargeback where the disputed amount is withdrawn from the merchant's account.
Dispute EventsmerchantStringCritical & Required
The identifier of the merchant. This field uniquely identifies the merchant, and should not be confused with the MID. Any unique identifier is accepted.
Dispute EventschargebackreasonStringCritical & Required
Reason for the chargeback.