FAQ
General Information
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-related or friendly fraud.
What type of AI models do you use?
- Supervised Learning: Fraudio mainly uses supervised learning techniques for scoring transactions. Supervised learning is a machine learning technique where the models learn how to map input to a label, which in the case of fraud detection is whether the transaction is fraud or not. Tree-Based Models, such as Random Forests, Gradient Boosted Trees, and XGBoost, are predominantly used for the majority of models. The key advantage of these Tree-Based Models is their ability to provide explanations, aiding in the comprehension of why a transaction is marked as fraudulent or not.
- Unsupervised Learning: To augment the effectiveness of supervised learning, Fraudio also employs unsupervised learning techniques. These are particularly adept at uncovering novel and previously unknown fraud patterns. Unsupervised learning operates on the principle of anomaly detection within the data, functioning independently of predefined labels. This approach is instrumental in enhancing the system’s ability to identify and adapt to emerging fraudulent behaviors.
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.
API Usage
How do we start using the product in an API Test Environment?
Once you have received your API keys, you're already in an API Test Environment. Therefore, you can immediately start using the product for testing.
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. So once you are finished with testing and once you the data quality has been approced, you will receive the production keys. The API Test Environment environment is active from the outset, facilitating comprehensive testing before going live.
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 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 or webhook, and are also accessible through our dashboards.
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.
Why is the response in the API Test Environment the same regardless of the values sent?
In the API Test Environment, a dummy model is deployed. The outcome of reports should only be utilized for testing purpose.
What is the rate-limiting on the Fraud Score 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, it 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.
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.
Data Mapping
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 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.
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.
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.
What is the difference between merchant, mid, acceptor, and acceptordevice?
We define the merchant hierarchy as follows:
Merchant:
- The overarching entity or business that contracts with an acquiring bank to accept card payments.
- A Merchant's ID is used to uniquely identify the merchant within the acquirer's system.
- Example: Mercadona has the Merchant Name
Mercadonaand Merchant ID12345.
MID:
- A merchant can have multiple MIDs for different business purposes or operational segments.
- Example:
- MID
123for Ecom related transactions. - MID
456for in-store POS transactions.
- MID
Acceptor:
- Represents a logical entity that aggregates transactions from a specific location or function. It typically corresponds to a store, branch, or department.
- Each acceptor is identified by an Acceptor ID, which acts as an intermediary for routing transactions from multiple devices.
- Example: A local Mercadona supermarket is represented by Acceptor ID
789.
Acceptor Device:
- Refers to the physical or virtual devices that handle card transactions, such as Point-of-Sale (POS) terminals, vending machines, or online gateways.
- Each device is associated with a specific acceptor and is uniquely identified by an Acceptor Device ID.
- Example: A local supermarket might have multiple devices, e.g., Acceptor Device ID
66235for one of the POS terminals.
What is historical data, and how can I transfer it?
Historical data comprises of payment transactions, merchant meta-data 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!
Data Policy
What is Fraudio's policy around data retention?
We retain customer data for 7 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. Where can I find information about the AI models that you use? 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.
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.
Product Specifics
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 information is in a Merchant Initiated Fraud report?
The Merchant Initiated Fraud reports are 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.