transaction restrictions

The system supports referral restrictions, which enable the consistency checking of attributes within the same transaction. This is based on predefined parameters and velocity restrictions. Velocity restrictions allow the configuration of the rate at which specific transaction attributes can change relative to other transactions that are linked by a common attribute. These checks can be applied on a daily, weekly, or monthly basis.

1. BIN: the bank identification number for the source credit card. This is a unique identifier assigned to the bank that issued the source credit card, used to identify the institution in transactions.
2. BINRange: the bank identification number range for the source credit card. This range covers all the possible numbers associated with the product of the source credit card, helping to verify the card’s validity.
3. CardEnd: the last four digits of the source credit card number. These digits are often used for verification purposes and to mask the full credit card number for security reasons.
4. HashID: unique identifier for the source credit card. This is a distinct identifier assigned to each credit card to ensure it can be uniquely identified in the system.
5. BinCountry: country identifier for the BINRange of the source credit card, might be different from the formal Issuing bank country. This identifier specifies the country where the bank that issued the source credit card is located.
6. CardHolder: name of the cardholder for the source credit card. The name of the individual who owns the source credit card, used for verification and transaction purposes.
7. CardExpMonth: card expiration month. The month when the source credit card expires, required for processing transactions.
8. CardExpYear: card expiration year. The year when the source credit card expires, needed for validating transactions.
9. CardType: type of the source credit card. Specifies the category of the source credit card (e.g., Visa, MasterCard) to facilitate transaction processing.

1. CustBirthday: customer’s birthdate. The birthdate of the customer, often used for verification and fraud prevention.
2. CustEmail: customer’s email. The email address of the customer, used for communication and transaction notifications.
3. CustIP: customer’s IP address. The IP address from which the customer is accessing the service, used for security and fraud detection.
4. CustIPCountry: country identifier for the customer’s IP. Identifies the country associated with the customer’s IP address, aiding in fraud detection and localization, based on MaxMind GeoIP.
5. CustFirstName: customer’s first name. The first name of the customer, used in identification and communication.
6. CustLastName: customer’s last name. The last name of the customer, used for verification and records.
7. CustPhone: customer’s phone number. The phone number of the customer, used for contact and verification purposes.
8. Country: identifier for the billing country. This identifier specifies the country associated with the billing address of the customer.
9. State: identifier for the billing state. This identifier specifies the state or region within the billing country of the customer.
10. CustomerFingerprint: identifier for the customer fingerprint. A unique identifier representing the customer’s distinct attributes or profile within the system, based on FingerprintJS.

1. DstBIN: the bank identification number for the destination credit card. A unique identifier for the bank that issued the destination credit card, used in processing transactions.
2. DstBINRange: the bank identification number range for the destination credit card. This range includes all possible numbers associated with the product of the destination credit card, helping to verify the card’s validity.
3. DstCardEnd: the last four digits of the destination credit card number. These digits are used for verification and security purposes when processing transactions.
4. DstHashID: unique identifier for the destination credit card. A distinct identifier for the destination credit card, ensuring it can be uniquely recognized in the system.
5. DstBinCountry: country identifier for the BINRange of the destination credit card. Specifies the country where the bank issuing the destination credit card is located, might be different from the formal Issuing bank country.
6. DstCardType: type of the destination credit card. Indicates the category of the destination credit card (e.g., Visa, MasterCard) for transaction processing.
7. DstCardHolder: name of the cardholder for the destination credit card. The name of the individual owning the destination credit card, used for verification.

1. AcctNumber: IBAN or SEPA account number. The International Bank Account Number (IBAN) or Single Euro Payments Area (SEPA) account number used for transactions.

1. RecvEmail: receiver’s email address. The email address of the receiver, used for communication and transaction confirmation.
2. RecvFirstName: receiver’s first name. The first name of the receiver, used for identification and communication.
3. RecvLastName: receiver’s last name. The last name of the receiver, used for verification and records.
4. RecvPhone: receiver’s phone number. The phone number of the receiver, used for contact and verification purposes.

1. TransactionType: identifier for the transaction type. Specifies the type of transaction being processed (e.g., sale, transfer).
2. TxAmount: transaction amount. The total amount of money involved in the transaction.
3. CreatedDate: transaction creation date. The date when the transaction was initiated.
4. Currency: identifier for the transaction currency. Specifies the currency used in the transaction (e.g., USD, EUR).
5. TxInvoiceNo: transaction invoice number assigned by the merchant. A unique number assigned by the merchant to the transaction for tracking and reference.
6. MerchantIP: merchant’s IP address. The IP address from which the merchant operates, used for security and verification.

1. Merchant: merchant’s identifier. A unique identifier for the merchant within the system.
2. Requestor: identifier for the integration point. Specifies the integration point used in the transaction process.
3. Blueprint: identifier for the blueprint. Identifies the blueprint or template used in the transaction or system setup.
4. BankTerminal: identifier for the bank terminal used to process the transaction. Specifies the terminal through which the transaction was processed.
5. GatewayDescriptor: descriptor for the bank terminal. A descriptive name or label for the bank terminal.
6. MerchantIdentifier: merchant identifier for the bank terminal. The identifier linking the merchant to the specific bank terminal used.
7. Provider: identifier for the payment provider. Specifies the payment provider involved in processing the transaction.

The system enables additional checks to be performed using minFraud. For pricing please contact you manager.

1. Verify if the customer’s IP address is from an anonymous VPN: Determine whether the customer’s IP address is associated with a Virtual Private Network (VPN) that is designed to anonymize the user’s internet activity, which could indicate an attempt to mask their true location or identity.
2. Verify if the customer’s IP address is anonymous: Check if the customer’s IP address is linked to services or methods that anonymize internet usage, making it difficult to trace the user’s actual identity or location.
3. Verify if the customer’s IP address belongs to a hosting provider: Determine whether the IP address is registered to a web hosting provider, which could suggest that the IP is being used by a server rather than a typical residential or mobile user.
4. Verify if the customer’s IP address is from a public proxy: Check if the IP address is linked to a public proxy server, which allows multiple users to route their internet traffic through the same IP address, often to bypass restrictions or for anonymity.
5. Verify if the customer’s IP address is from a residential proxy: Determine if the IP address belongs to a residential proxy service, which uses IP addresses from residential ISPs to mask the true source of internet traffic, often used to appear as a regular residential user.
6. Verify if the customer’s IP address is a Tor exit node: Check if the IP address is an exit node in the Tor network, where encrypted traffic from Tor users exits to the public internet, often used to enhance privacy and bypass censorship.
7. Check the static IP score for the customer: Assess the static IP score, which evaluates the likelihood that the customer’s IP address is static (fixed) rather than dynamic (changing), indicating a stable and consistent connection.
8. Check the number of users associated with the customer’s IP address: Determine how many unique users are linked to the customer’s IP address, which can help identify shared connections or unusual usage patterns.
9. Check the user type associated with the customer’s IP address: Identify the category or type of user associated with the IP address, such as residential, business, educational, or mobile, to better understand the context of the user’s internet activity.

Referral Restrictions Example:

• Scenario: Ensuring that the country of the IP address matches the country associated with the source credit card number. The system can be configured to check if the country of the IP address used for the transaction is consistent with the country of the issuing bank of the source credit card. This helps in identifying potential fraud where the transaction is being initiated from a different country than the card issuer.
• Example: A transaction where the source credit card is issued by a bank in the United States and the IP address is also located in the United States would pass the referral filter. However, if the IP address is located in another country, such as Russia, this discrepancy might trigger an alert for further review.

This approach helps to ensure that the geographical location of the transaction aligns with the expected location based on the card issuer, thus adding an additional layer of security.

Velocity Restrictions Example:

The system offers an advanced mechanism for detecting and preventing fraudulent activities by allowing for the configuration of velocity restrictions with associated fraud scores. This enables a nuanced approach to transaction monitoring and decision-making based on the cumulative risk score. Here’s how it works:

Velocity Restrictions:

• Definition: Velocity restrictions monitor the rate at which certain attributes of transactions change. In this context, it tracks how frequently the same destination credit card is used with different source credit cards from various countries.
• Daily Monitoring: The system checks for high-frequency usage of the same destination credit card with source credit cards from different countries within a single day.
  • Example: If the same destination credit card ending in “5678” is used with source credit cards from the USA, Germany, and Brazil all in one day, it indicates potential fraud. This might be assigned a high fraud score due to the suspicious nature of rapid international transactions.
• Monthly Monitoring: The system also monitors the usage over a month to identify patterns that are spread out over time.
  • Example: If the same destination credit card ending in “5678” is used with source credit cards from the USA, Germany, Brazil, and Japan over a month, it is less likely to be flagged as fraudulent. This scenario might be assigned a lower fraud score.

Fraud Score Configuration:

• Fraud Score Assignment: For each velocity restriction, a specific fraud score can be assigned based on the perceived risk. For example:
  • High-frequency usage in a single day might be assigned a fraud score of 80.
  • Usage spread over a month might be assigned a fraud score of 20.
• Cumulative Score Calculation: The system calculates the sum of fraud scores from multiple velocity restrictions and other risk factors for a given transaction. This cumulative score helps in assessing the overall risk associated with the transaction.

Transaction Decision-Making:

• Threshold Setting: The system allows for setting a threshold for the cumulative fraud score. Transactions exceeding this threshold can be automatically declined, while those below can proceed.
  • Example: If the threshold is set at 100, and a transaction accumulates a fraud score of 120 from various checks (e.g., high daily usage frequency combined with other risk factors), the transaction would be declined.
• Automated Decline: Based on the cumulative fraud score, the system can automatically decline high-risk transactions, preventing potential fraud before it occurs.
  • Example: A transaction involving the destination credit card ending in “5678” with source cards from multiple countries within a day (fraud score of 80) combined with other suspicious activities (additional fraud scores totaling 50) would result in a cumulative score of 130, leading to an automatic decline.

By incorporating fraud scores and cumulative score thresholds into velocity restrictions, the system ensures a robust, dynamic approach to fraud detection and prevention. This method allows for fine-tuning and adaptability, effectively balancing security and customer experience by declining only the transactions that pose significant risks.