FAQ
General & Legal Questions
What is Fraudio's policy around data retention?
We retain customer data for 5 years from the reception date to ensure ongoing model training and the highest level of performance of our fraud detection products. This is considered a legitimate interest in improving our service. However, if you have specific requirements for data retention due to legal regulations that you need to comply with, please let us know so we can adapt to your specifications.
Our unique approach utilises all customer data for the benefit of other customers, providing the most effective consumer protection. If a customer terminates their relationship with us, they can always request that we delete their data, as outlined in our Data Processing Agreement.
Our models, which are exposed to customers via our APIs, do not include any Personally Identifiable Information (PII). Similarly, the data exposed to customers via our user dashboards does not include PII, unless the customer specifically requests access to their own PII data for fraud detection or reduction purposes.
What are Fraudio's obligations with regard to PCI certification?
Fraudio is exempt from PCI certification requirements, as we process only truncated PAN and hashed data. According to PCI regulations, this does not necessitate PCI certification because we do not handle full payment card details.
Mapping
Are the data fields merchantcountry, merchantcity, and merchantstreetaddress customer information, or the customer's merchant information?
These fields are the customer's merchant information.
Where can I find information about the AI model that you use?
Our AI model is a combination of different methods and algorithms, such as tree-based models, supervised and unsupervised learning, and others. We do not have a document that describes our model in detail.
What is the difference between authresult and success?
- The success field indicates whether a transaction was successfully completed without any technical errors, which includes that it succesfully passed the gateway and all authentication and authorization checks (explained further below).
- The authresult field simply indicates whether a transaction successfully passed all authentication and authorization checks, and does not necessarily reflect whether the transaction was ultimately successful or not.
- For example, it is possible for a transaction to fail for technical reasons (success=false) even if it passed all authentication and authorization checks (authresult=success).
- A transaction can be declined by the gateway and not even reach the authentication and authorization checks, resulting in a success value of false and an authresult value of none.
- In some cases, a processor has the gateway set after the authentication and authorization checks are done, resulting in an authresult value of success and a success value of false.
- It is not possible for a transaction to fail both an authentication test and an authorization test and still be successful.
- The none value for either field is used when the relevant information is not available, not applicable, or unknown.
What is historical data, and how can I transfer it?
Historical data comprises payment transactions and chargebacks. Fraudio uses this data to enhance fraud detection models. Share files with Fraudio by uploading CSV files to our Amazon S3 storage, which is secure and compliant with privacy regulations. Upon request, we will provide a secure key ID and secret for file uploading to a designated folder. There are various S3 clients available for uploading, such as command-line interfaces, GUIs, and client-side libraries for most programming languages.
For more information on transferring data, refer to the batch transfer manual. If you prefer alternative methods for sending data, please contact us. Remember, more data results in better fraud scores!
What is pre- and post- authorization data?
A payment transaction is a set of information about money that flows from an entity (the payer) to another entity (the beneficiary) through the payment ecosystem. As the transaction is processed by different entities (e.g., payment gateway, acquirer, issuer), it requires authorization from the payer's bank.
- The information a transaction holds before seeking authorization is called pre-authorization information.
- The information obtained after a transaction is authorised by the issuing bank is called post-authorization information.
Why do I need to send post-authorization data?
Post-authorization data is crucial for maximizing the benefits of Fraudio's products. We use this data to provide historical context to transactions.
Can I send data just post-authorization?
Generally, you should send pre-authorization transaction data to Fraudio. Depending on your role in the payment ecosystem, you might want to detect fraud using our payment fraud detection product after transaction authorization. In both cases, send us both pre- and post-authorization information to accurately detect fraud.
Score your transaction using pre-authorization information and submit post-authorization information as soon as it's available. This is mandatory. To send post-authorization information, connect to the Payment Post-Authorization Enrichment API endpoint. If you cannot send pre-authorization data due to your position in the payments ecosystem, score transactions after authorization by sending all information (pre- and post-authorization) within the same transaction to the fraud score API endpoint.
Can I integrate with the Merchant-Initiated Fraud detection product without the Payment Fraud Detection product?
Yes, you can integrate with the Merchant-Initiated Fraud detection product without the Payment Fraud Detection product. However, you will still need to follow the steps related to the Payment Fraud Detection product, but you won't need to purchase both products.
What is the difference between the cardholderphonenumber field and the shopperphonenumber field?
The cardholderphonenumber field contains the phone number of the person whose name is on the card, while the shopperphonenumber field contains the phone number of the person making the purchase. These fields may be used for different purposes.
For example, the cardholderphonenumber field could be used by the issuing bank to contact the cardholder in case of suspicious activity or a potential fraud issue. The shopperphonenumber field, on the other hand, could be used by the merchant to contact the shopper for customer service or delivery purposes. (The same thing applies to the email addresses.)
Does the transactionid have to be unique? If so, why does the score change when you call it with the same transactionid?
Yes, the transactionid should be unique. The score will depend on other fields, such as the amount and the merchant. When scoring transactions, we take into account the previous transaction from the same card and merchant. Therefore, if two transactions with the same ID and information are sent, the scores can differ.
What is meant by the term "precision"?
Precision refers to the level of accuracy or correctness in detecting fraud. It is calculated by determining the ratio of true positives (i.e., correctly identified instances of fraud) to the total number of positives (both true positives and false positives).
In other words, precision measures how well we are able to accurately detect fraudulent activity without incorrectly flagging legitimate transactions as fraudulent.
For example, if a precision rate of 10% is achieved, it implies that out of all transactions flagged, only a small proportion (10%) were actually cases of fraud, with the majority (90%) being legitimate transactions that were erroneously identified as fraudulent.
What is meant by the term "recall"?
"Recall" refers to the percentage of fraud attempts that are successfully blocked by fraud prevention measures. For example, if a company has a recall rate of 50%, it means that they are able to successfully prevent 50% of attempted fraud.
How does the transition from testing in the API Test Environment to going live work?
Transitioning from the API Test Environment testing to live operation occurs upon request. The API Test Environment environment is active from the outset, facilitating comprehensive testing before going live.
On a scale of 1 to 10: if all available mandatory data is rated at 10, where would our current level of missing data place us?
It's challenging to assign a numerical value to missing data. To assess model performance accurately, a substantial volume of transactions and fraud labels needs to be received, along with an understanding of the types of values we receive in your requests.
How are the transactionid and parenttransactionid linked together?
Here is an example of how the transactionid and parenttransactionid fields are linked together:
| transactionid | parenttransactionid | |
|---|---|---|
| auth | 123 | none |
| capture | 534 | 123 |
| refund | refund_123 | 123 |
If we call the scoring endpoint before performing 3DS, should the API be set to true if 3DS will be performed later?
Yes, it is advisable to set the scoring API to true if 3DS will be performed after calling the scoring endpoint, even if 3DS hasn't yet been performed. This practice allows the API to generate a more accurate score by considering the anticipated impact of 3DS on the transaction's risk level, thereby improving fraud prevention measures.
Should we set the cvvused value to "none" instead of "false" if it's uncertain whether the CVV checks will be completed by the time we call the scoring API?
Yes, it would be more appropriate to set the cvvused field to "none" if the CVV check status is uncertain at the time of calling the scoring API. This setting allows the API to use other available data to generate a more accurate score. Setting the value to "false" may lead to inaccuracies as it implies that a CVV check has been attempted and subsequently failed.
Can there be a difference between the acceptor and the merchant in the case of ecom transactions?
Yes, even in the case of ecom transactions, there can be a difference between the acceptor and the merchant. A merchant may receive ecom transactions from one part of the business at one acceptor, and from another part of the business at a different acceptor. However, it's generally true that the difference is less pronounced in the context of ecom.
Is the "acceptor" field referring to customer information or the customer’s merchant information?
The "acceptor" field refers to the merchant information.
Engineering & Technical
Can you clarify the direction of data exchange for the endpoint integration? Is it solely from our system to yours, or is there reciprocal communication?
Ordinarily, the data exchange is unidirectional – your system makes API calls to the Fraudio system and subsequently receives responses. Nevertheless, should your requirements dictate, we are capable of supporting webhooks to provide supplementary data.
Can you explain the term 'Scoring time' and its implications for using the fraud score endpoint versus the Post-Authorization Backfill endpoint?
'Scoring time' refers to the point at which we evaluate a live transaction and provide you with a real-time fraud score. If you're able to supply all requested transaction data at scoring time, there's no need to send it again via the post-authorization backfill endpoint. Conversely, if you're unable to provide post-authorization transaction data at scoring time, it must be sent through the post-authorization backfill endpoint. Failure to do so may lead to suboptimal fraud score performance.
How does Fraudio enable responses and recommendations for the MIF (merchant-initiated fraud) product?
Unlike our transaction fraud product that utilises an API, MIF operates differently. The response and recommendations from MIF are not retrieved through an endpoint because the data is batched. Instead, we have implemented a system where reports are sent to a designated Slack channel and are also accessible through our interactive dashboards.
How can I request credentials for the APIs?
To request credentials for the APIs, contact your Fraudio representative or email support@fraudio.com to schedule an appointment.
How can the API Test Environment environment trigger red or yellow recommendations for downstream testing?
To initiate a red or yellow recommendation test reply in the API Test Environment environment, you can set the header X-Fraudio-Recommendation accordingly. Setting it to "red" will generate a red recommendation test reply, while setting it to "yellow" will produce a yellow recommendation.
Does utilising a single set of API keys for multiple acquirers influence the reporting or portal access on Fraudio's end?
Utilising a single set of API keys across multiple acquirers can indeed have implications. It places significant reliance on maintaining high data quality and accurate customer naming within API calls, as these factors become the sole means of segregating customer data for our Tableau reports.
It's also crucial to initiate new customers on the Fraudio API Test Environment environment until we confirm that the data is ready to transition to the live environment (via switching to production keys). This approach helps prevent potential performance issues caused by low-quality data affecting our aggregate calculations.
Historically, the choice of API key used provided a measure of control over data routing in our downstream systems. Therefore, to maintain internal controls and mitigate errors, we recommend allocating a dedicated set of API keys (for both production and testing) to each client. This strategy diminishes the need for disambiguation based solely on customer names, offering a more secure guard against potential mistakes.
What information does a Merchant-Initiated Fraud detection report include?
Merchant-initiated fraud detection reports are delivered in two primary ways:
- The Fraudio Alert Report, which is sent via Slack and designed for integration with your systems.
- Our interactive Merchant Fraud Dashboards.
If you'd like, we can arrange a demonstration to help you better understand how these tools work.
Fraudio Alert Report
The Fraudio Alert Report is delivered in JSON format. Here is an example:
{
"merchant":"8v124u87z4",
"fraudflag":"red",
"score": 0.88158123,
"reasoncode":"Large fraction of high risk transactions that is CNP. Detected a relatively large amount of high risk transactions, when compared to the merchant's peer group. Detected outlying sequence of failed transactions, when compared to the merchant's peer group. (Between 2022-02-07 11:59 and 2022-03-09 11:59.)"
}
The components of the report are:
merchant: This refers to your provided merchant ID. If you need information about a specific merchant, please supply the corresponding merchant ID.fraudflag: This field indicates the suggested action to be taken. Options include Black, Red, or Yellow. These recommendations are determined by the thresholds you have set.score: This is the calculated fraud score, ranging between 0 and 1. A score closer to 1 indicates a higher likelihood of fraudulent activity.reasoncode: This contains important details about the alert, including why it was triggered and the sequence of transactions leading up to it.
Does the Merchant Initiated Fraud Detection (MIF) product contain the same endpoints as Payment Fraud Detection (PFD) plus the following ones?
Yes, they both contain the same endpoints. Here is a recap:
- Payment Fraud Score: This endpoint consumes real-time payment transactions and produces fraud scores and recommendations for both PFD and MIF.
- Payment Post-Authorization Enrichment: This endpoint consumes post-authorization payment transaction data for both PFD and MIF.
- Dispute Events: This endpoint consumes chargebacks and other fraud notifications/reports for both PFD and MIF.
- Merchant Account Information: This endpoint consumes merchant metadata like registration date and KYB information for MIF.
- Inter Account Transfers: This endpoint consumes credit transfers between known wallets and bank accounts for MIF.
- Account Bank Transfers: This endpoint consumes transfers in and out of wallets and/or bank accounts for MIF.
- Merchant Evaluations: This endpoint consumes feedback about the merchant fraud scores that you have evaluated for MIF.
Why is the response in the API Test Environment the same regardless of the values sent?
In the API Test Environment, a model simulator runs to provide a fake "score". Hence, the response doesn't reflect the actual values sent.
What is the rate-limiting on this endpoint?
The scoring endpoint is designed to scale up to meet the required demand, thereby avoiding rate-limiting constraints.
Is the "Transaction_ID" an echo of an ID submitted by the client?
Yes, the transactionid is a reflection of the transaction ID provided by the client.
Are all response fields returned as strings?
Yes, all response fields are returned as string data types.
Is it possible to have scores with 2 or 3 decimal places?
Yes, the "Score" can be rounded to 2 or 3 decimal places without issue.
Can we send data to an S3 bucket in JSON format?
Yes, data can indeed be sent to an S3 bucket in JSON format.
How do we start using the product in a API Test Environment?
Once you have received your API keys, you're already in a API Test Environment environment. Therefore, you can immediately start using the product for testing.
Will we get new endpoints and API keys once we go live?
No, the same endpoints and API keys will continue to be used when you transition to the live environment.
Batch integration
How should fraud notifications be sent to Fraudio?
Fraudio receives transaction fraud notifications through the dispute events endpoint, and merchant fraud notifications through the merchant evaluations endpoint. For further details, please refer to the Folder and File Structures page.
Do we need to delete files after a certain period, or should we just keep them?
You are not required to delete any files. Fraudio typically retains files for a period of five years before deleting them. Rest assured, your data remains safe and encrypted throughout this period, preventing unauthorised access.
What should we do if a report is accidentally deleted?
In the event of accidental deletion of a report, please inform Fraudio immediately. We will assess the situation and, if necessary, generate a new report for you.
Sales & Handover
How does the implementation of 3D Secure (3DS) affect the application of Fraudio's products?
Fraudio assists clients in deciding on appropriate risk thresholds in line with their level of fraud, and provides three recommendation levels:
- Green: Indicates a low fraud probability; no action is necessary, including the addition of 3DS.
- Yellow: A medium fraud probability; a secondary assessment or 3DS is advisable.
- Red: High fraud probability; transaction blocking is advised.
These risk thresholds consider factors such as your risk appetite, business model, and follow-up actions. Setting a higher threshold means fewer transactions will be blocked, but also less fraud prevention. Coupling flexible threshold usage with dynamic 3DS allows for creating optimal conversion paths for customers, from those deemed entirely non-fraudulent to higher-risk ones made safer through 3DS.
Besides providing automated recommendations, Fraudio can further enhance your fraud prevention with ID and device verification solutions. These can optimise the decision-making around 3DS usage.
What is the difference between static 3DS and dynamic 3DS?
Dynamic 3DS means that you can decide whether to use 3D Secure (3DS) or not for each transaction, instead of having it always on or off. 3DS is a security feature that verifies the identity of the cardholder and reduces fraud. With dynamic 3DS, you can set some criteria to enable or disable 3DS based on the risk level of the transaction or the customer profile. For example, you can skip 3DS for transactions that are very low-risk or for customers that are very trustworthy. This way, you can optimize the customer experience and the security level for each transaction.
What types of fraud does Fraudio detect?
Fraudio is equipped to detect various types of fraudulent activity. These include:
- Payment Fraud Detection (PFD) – This occurs when a merchant falls victim to the illicit use of credit or debit cards.
- Merchant Initiated Fraud (MIF) – In this scenario, the merchant themselves is the perpetrator of fraud.
- Money Laundering – This refers to the process of making illegally-gained proceeds appear legal.
Please note that Fraudio does not currently detect service or 'friendly' fraud.
What are Fraudio's Recovery Point Objective (RPO) and Recovery Time Objective (RTO) in terms of data backup?
At Fraudio, we take data security seriously. As such, we perform daily backups of our data blobs and store these in different regions to ensure quick recovery in the event of a data loss incident.
Can Fraudio share its business continuity plan?
While we are unable to disclose detailed specifics of our business continuity plan, rest assured that our service level agreement (SLA) represents the robust continuity measures we have implemented. We follow industry best practices to ensure business continuity.
What are the contact details for general support?
You can reach our support team via email at support@fraudio.com. For engineering-specific queries, please write to engineering-support@fraudio.com.
Please note that we currently do not offer phone support.
Billing
Will the minimum monthly fee be charged only if no transactions were sent? If we send a small number of transactions, will the fee apply per transaction?
The monthly minimum fee applies based on the assigned tier and the number of billable transactions sent to Fraudio's API. Each tier is designated based on the volume of transactions. If the number of transactions sent exceeds the monthly minimum associated with your tier (as per the agreed price per transaction), the additional cost will be added to the monthly minimum fee.
Are there any additional fees besides the per-transaction fees? For example, is there a monthly fee?
Apart from the per-transaction fee, there are no additional monthly fees. However, we do have a monthly minimum fee, as stipulated in your contract. This fee will be charged even if no transactions are sent during that month.
Do you provide an invoice listing all the transactions?
No, we provide an invoice showing the total number of scored transactions and the associated fee per transaction, rather than a detailed list of individual transactions.
How often are invoices issued?
Invoices are issued on a monthly basis.
What is Fraudio’s invoicing criteria and how does it relate to the billing engine in terms of included transactions? How are the API calls measured for each customer?
We measure API calls, specifically counting accounts of a certain type. Then, we estimate authorizations and auth_captures. Transactions sent to other endpoints, such as chargeback and post-backfill, are not taken into consideration, and thus are not billed.