iSpyFraud

iSpyFraud

Detect Fraud Before it happens

with iSpyFraud

Sixty-two percent of companies were subjected to attempted or actual payment fraud in 20141. As the payment processing landscape continues to evolve, the opportunities for fraudulent activity will as well; with the expected rise in credit card use and the advance of mobile payment technology, it is predicted that the need for cyber security around payment processes will only increase. iSpyFraud's software allows a merchant to anticipate and defend against fraudulent activity. Merchants can configure extensive filters to detect suspicious transactions before they're approved, and additionally, are provided with enhanced reporting capabilities that give them access to all the information they need to root out fraudsters for good.

Who Needs iSpyFraud?

How does iSpyFraud Work?

Although most businesses could benefit from With iSpyFraud, merchants will have the ability to: advanced security when accepting payments, some  merchants are particularly prone to fraud: Set rule-based parameters for transactions, defining such things as transaction volume per  Merchants in what would be considered a high- user, maximum amount charged in one risk business, including but not limited to transaction, and more electronics, subscription-based sales, weapons,  Quickly and easily review transactions in any fantasy sports, online gambling, and financial state, whether approved or not consulting  Access accurate and consolidated reports  Merchants who process a high volume of detailing the ins and outs of each transaction transactions, particularly card-not-present  Merchants with international clientele 1. Association for Financial Professionals, "Payments Fraud and Control Survey: Report of Survey Results," chase.com, accessed September 2015. https://www.chase.com/content/dam/chasecom/en/commercial-bank/executive-connect/common/document/afp-payments-fraud-results.pdf

Get in touch with us to learn more:

iSpyFraud Detailed Guide

What is iSpyFraud? ......................................................................................................................... 2 Basic Uses ........................................................................................................................................ 2 Getting Started ................................................................................................................................ 2 General Tab ..................................................................................................................................... 3 Thresholds Tab ................................................................................................................................ 3 User Ban Tab ................................................................................................................................... 5 Exceptions Tab ................................................................................................................................ 7 Waiting Review Tab ........................................................................................................................ 8 History Log Tab ............................................................................................................................... 9 Frequently Asked Questions ......................................................................................................... 10

What is iSpyFraud?

Welcome to the detailed user guide for iSpyFraud, a rule-set based fraud management utility that allows merchants to configure extensive filters to aid in the detection of fraud by screening transactions throughout the processing lifecycle. As it operates in real time, iSpyFraud can decline transactions both before and after authorization, which can potentially mitigate high chargeback volume and offer merchants peace of mind when it comes to their own security, as well as that of their customers.

Basic Uses

Though there are countless ways to use iSpyFraud based on varying scenarios merchants might encounter, there are certain uses of the software that could be considered universally relevant, including: 1. Monitoring and controlling transactions during a given timeframe by setting rules based on a combination of many parameters, including the following: a. Transaction count b. Transaction amount c. IP address d. User location e. Credit card number f. Credit card brand 2. Limiting internal credit card fraud or abuse attempts 3. Blocking transactions from specific countries 4. Reviewing suspect transactions in order to take action prior to settlement The following instructions will aid merchants in choosing the settings that will prove most useful for them depending on the specific needs of their business. In addition to this guide, assistance can be accessed through our support team, which can be reached at +(599 9) 8440012 from 8 am-5pm Atlantic Time, or at support@cxpay.cw.

Getting Started

When a merchant logs into the gateway, iSpyFraud can be found as a link under "Other Services" on the left side of the page. The link will take the merchant to the program's General tab. Other than geography bans on transactions from certain countries, there are no default settings in place. There are default geography bans on the following countries (as sent in the Country field): Afghanistan Albania Armenia Azerbaijan Bulgaria Czech Republic India Indonesia Iran (Islamic Republic of) Kazakhstan Kuwait Lithuania Macedonia, the Former Yugoslav Republic of Malaysia Pakistan Romania Russian Federation Turkey Ukraine Viet Nam Yugoslavia The countries on this list are frequently the origin of fraudulent international transactions. The merchant can remove any of them from the ban list at will (see User Ban tab section for instructions).

General Tab

The General tab gives basic information about what iSpyFraud does and has a brief overview of its contents. Note the tabs at the top of the screen, which browse to different sections within the iSpyFraud console.

Thresholds Tab

The Thresholds tab allows a merchant to set a variety of parameters on attempted or approved transactions, and these rules give the merchant the option to either Flag for Review or Deny Transaction. There are two main sections, titled Add/Edit Credit Card Rules and Add/Edit IP Address Rules, and the options in each section direct the merchant to set a threshold on a certain aspect of a transaction. These thresholds can be set in a combination of ways to track and/or block certain types of activity that may point to fraud. For example, there are two rules pertaining to single transaction amount. If the merchant doesn't sell anything under $20, they can set transactions for anything less than $20 to be flagged for review or denied. This can help prevent card testing, in which a fraudster might charge small amounts to a large number of credit cards. In another case, a merchant with a subscription-based business might use the option to limit attempted number of transactions; the merchant can flag for review transactions beyond the initial subscription fee that come from the same IP address within the same day to ensure that they're not fraudulent. To set thresholds, the merchant simply chooses (if applicable) whether they wish to screen attempted or approved transactions (drop-down), enters the desired values, and then chooses whether the end result of a suspicious transaction should be to flag it for review or deny its approval (dropdown). Once these choices have been made, the merchant clicks "Update." Each rule must be updated individually. For a more in-depth look at some possible uses of the Thresholds tab, see Use Cases.

User Ban Tab

The bans/flags in this tab are considered static, in the sense that they don't depend on the behavior of the user (the consumer). In each section, the merchant chooses what users or types of users to ban/flag, and any transactions originating with those users will either be banned outright or flagged for review, depending on the merchant's selections. Each section gives the option to View current bans and Add new bans. When the merchant clicks to the "View" screen, they also have the option to Delete any currently banned users. There are seven sections in the User Ban tab: 1. IP Addresses a. Merchants can ban/flag a single IP, multiple IPs from the same block, or a range of IPs b. Merchants can specify a timeframe (number of days) in which to ban/flag IPs, or make the ban/flag indefinite 2. Credit Cards a. Merchants can ban/flag a single credit card number, multiple credit card numbers, or all credit card numbers with matching BINs b. Merchant can specify a timeframe (number of days) in which to ban/flag credit card numbers, or make the ban/flag indefinite 3. Geographical Information a. Merchants can ban/flag transactions from any country b. Merchants can specify a timeframe (number of days) in which to ban/flag a country, or make the ban/flag indefinite c. A ban/flag on a specific country will automatically check for any billing/shipping addresses from that country and ban/flag users based on that information, and the merchant can also choose whether or not to verify IP addresses from that country 4. US/Non-US IP Ban a. Merchants can choose three actions (Nothing, Ban, or Flag for Review) for transactions that have a billing country of US but a source IP address outside the US i. Unlike with the other sections in this tab, there is no timeframe specified for this ban ii. Merchants who do not send the Country field with their transactions can set a US Country Default, which will assume (for the purposes of this particular ban) that the Billing Country is the US. 5. User Information a. Merchants can ban/flag specific customers based on customer user IDs, which merchants can assign via the use of Customer Vault. User IDs outside of Customer Vault can also be submitted by the merchant via API or by providing the billing email in the transaction b. Merchants can specify a timeframe (number of days) in which to ban/flag certain users, or make the ban/flag indefinite 6. Email Address a. Merchants can ban/flag customers by email address, or ban/flag any customer using an email address with a particular domain b. Merchants can specify a timeframe (number of days) in which to ban/flag certain emails or domains, or make the ban/flag indefinite 7. Batch Ban a. Merchants can upload up to 5000 entries for a specific ban type at once b. Types can be chosen using the radio buttons above the Batch Data Box-merchants can select from IP/Range, Credit Card/Bank, User ID, and Email i. Only one type of data may be uploaded at a time c. Merchants can specify a timeframe (number of days) in which to ban/flag certain values, or make the ban/flag indefinite Note: For any of the IP Address selections to work, the Merchant must collect the public-facing IP address from the consumer and provide it with the transaction. For a more in-depth look at some possible uses of the User Ban tab, see Use Cases.

Exceptions Tab

The Exceptions tab goes hand in hand with the User Ban tab, and is considered the "whitelist" to the User Ban's "blacklist." In other words, merchants can use the Exceptions tab to make concessions for certain known users that would otherwise be banned or flagged under the restrictions in the User Ban tab. Any exception overrules all other rules. For example, if credit card 4111111111111111 is added to exceptions, the domain @gmail.com is banned, and the country Canada is banned, a transaction using "4111111111111111, test@gmail.com, and Canada" will be approved. Merchants can create exceptions for  IP Address  Credit Card  User ID  Email Address Exception values can also be uploaded using the same process as batch bans.

Waiting Review Tab

Merchants can view and take action on flagged transactions here; merchants can either void transactions that are in waiting review or allow them to settle by indicating that the review is complete. If no action is taken, transactions awaiting review will settle at the time set in the Merchant's Settlement Schedule. Merchants will be able to see which rule triggered the review.

History Log Tab

The History Log offers the merchant a searchable record of all transactions scrubbed by iSpyFraud. This log is useful for a merchant who is trying to assess the risk of potential fraud, or to evaluate known fraud patterns. A drop-down menu allows merchants to limit a search by time/date of transaction, and merchants can search by transaction ID, credit card number, email address, or IP address. The log is color coded by transaction status: Accepted (green), Review (yellow), Exception (blue), or Denied (red). For statuses of Review and Denied, a magnifying glass next to the response status allows merchants to see which rule was triggered.

Frequently Asked Questions

Q: What types of merchants need iSpyFraud? A: Though all merchants can benefit from the reassurance a fraud scrubbing utility offers, it's true that some merchants are more likely to be targeted by fraudsters than others. For example, merchants who process international transactions are considered higher risk, as are those in certain verticals, such as online gambling, online dating, membership-only websites with adult content, or even unexpected ones like consumer electronics. Non-profits that accept donations are also at risk and can benefit from iSpyFraud, as they are often used by fraudsters for card testing/spinning schemes. It's also anticipated that as EMV cards become standard in card present transactions, there will be a rise in card not present fraud, meaning more e-commerce merchants will be at risk. iSpyFraud is an ideal solution to combat the predicted spike in online credit card fraud. Q: Does iSpyFraud work in card present transactions? A: Although iSpyFraud was originally designed for e-commerce, it works equally well for card present transactions. The software's thresholds and rules do not discriminate between retail and keyed transactions, nor is the utility's scrubbing ability restricted by transaction origin (API, Virtual Terminal, Batch Upload, etc.). Q: Can iSpyFraud block someone from coming to my website? A: No, iSpyFraud can only take action on transactions sent to the Gateway. It cannot block activity happening on a website prior to data being sent to the gateway. Merchants can speak to their hosting provider or web developer if they need to block an individual from accessing their website entirely. Q: I'd like to use iSpyFraud on my website, but I don't want to use the Gateway to process. Is this possible? A: No, iSpyFraud is an additional service that can be added onto a gateway account to scrub transactions processing through it. It cannot be used as a standalone service. Merchants must be processing through the gateway to take advantage of the iSpyFraud scrubbing service.

iSpyFraud Merchant Use Cases

Use Case One: Restrict Transactions from Outside of Your Country .................................................. 2 Use Case Two: Protect Yourself from Card-Spinning/Card-Testing Fraud on your ecommerce website . 2 Use Case Three: Protect Yourself from Employee Fraud .................................................................. 3 Use Case Four: You Have Multiple MIDs but Don't Want Your Transactions Scrubbed on Every MID ... 4 Use Case Five: You Process Recurring Transactions and Don't Want to Accept Pre-Paid Cards ............. 4 Use Case One: Restrict Transactions from Outside of Your Country Merchants can use iSpyFraud to restrict transactions outside their own country in two ways: 1. User Ban>>Geographical Information>>Verify Country a. Using the Verify Country option, merchants can select to only look at the customer's billing/shipping addresses. This would prevent any transaction with a billing or shipping address outside the merchant's country from being processed (merchant can choose to either ban or flag for review) b. To ban/flag all countries other than their own, the merchant would simply highlight all countries except their own from the list in the Geographical Information section of the User Ban tab, then click "Add". 2. User Ban>>Geographical Information>>Verify IP Addresses a. If a merchant chooses to verify IP addresses in addition to billing/shipping addresses, iSpyFraud will also weed out transactions where the IP Address is physically located in the banned/flagged country. b. This option can only be selected in addition to the Verify Country option. Using both together is the safest method of screening for location by country, as a fraudster's physical location often does not match the submitted billing/shipping address. Example 1: If a merchant sells supplements but doesn't ship internationally due to regulatory laws, that merchant would most likely want to only verify a customer's country by billing/shipping address, rather than IP address, since the restriction they are most concerned with deals with where the merchandise goes, not necessarily where the transaction originates from. Although this provision isn't necessarily a case of fraud, this type of setting could help prevent chargebacks. Example 2: If a merchant is a non-profit organization that accepts donations from locals, they would most likely select Verify Country and IP Addresses. This will ensure that they are screening for users by physical location, rather than the location of the credit card owner-this is especially important in the case of entities that accept donations, as non-profits are commonly targeted by card-testing scams. Use Case Two: Protect Yourself from Card-Spinning/Card-Testing

Fraud on your ecommerce website

Card spinning, sometimes called card testing or simply carding, can be spotted in a number of different ways, including: 1. Many authorization attempts in a very short period of time a. If a merchant notices an unusually high amount of authorization attempts in a short amount of time, immediate evaluation of those transactions is warranted to assess whether or not fraud is occurring. The merchant should also consider contacting our support team to assist in a thorough evaluation. 2. The first six digits of the card (BIN) for multiple transactions are the same or similar a. In this case, a merchant can go to User Ban>>Credit Cards and enter the suspicious BIN, followed by a "*" (e.g. "411111*) and select whether to ban or flag that particular user. 3. The transaction amounts are very low ($.01 to $1.00) a. Typically, fraudsters who spin cards will first attempt a transaction for a very low amount, just to see if they can get an approval. To help screen this type of testing, a merchant can set a threshold that bans/flags transactions under a certain amount (such as $1.00). This might not be possible for certain merchants, as they might have legitimate transactions for amounts that low. 4. A spike in declined transactions in a merchant's reporting a. If a merchant notices an unusual amount of declined transactions, the best course of action may be to contact support to get help assessing whether or not there's fraud involved, and where it might be coming from. 5. Nonsensical names and/or emails, or the same name/email for multiple transactions in a short amount of time a. When something like this happens, a merchant can block the user(s) by selecting User Ban>>Email Address and enter the email(s) corresponding with the fraudulent transactions. If the merchant notices that all of the fraudulent transactions are coming from the same domain, the merchant can screen all emails from a specific domain by entering "*@emailaddress.com". Use Case Three: Protect Yourself from Employee Fraud Depending on the type of employee fraud and/or credit card abuse the merchant is experiencing, various actions can be taken. 1. If employees are entering amounts that are either higher or lower than the merchant's business requires, a minimum and/or maximum amount threshold can be implemented. a. To set a minimum amount threshold, go to Thresholds>>If single transaction amount is less than $[desired amount], enter the amount you want to screen for, choose the action you wish to take (Flag for Review or Deny Transaction), and click "Update". b. To set a maximum amount threshold, go to Thresholds>>If single transaction amount exceeds $[desired amount], enter the amount you want to screen for, choose the action you wish to take (Flag for Review or Deny Transaction), and click "Update". 2. If the card abuse is related to multiple transactions, or if a merchant's business model dictates that a customer's credit card should only be processed once in a given timeframe (e.g. in the case of a monthly subscription-based business), the merchant can set a credit card threshold to screen for inappropriate usage. a. To set a credit card threshold for daily use, go to Thresholds>>If daily attempted transaction count for CC exceeds [desired amount], enter the amount you wish to screen for, choose the action you wish to take (Flag for Review or Deny Transaction), and click "Update" i. The same process can be done for weekly, monthly, and yearly transaction counts. Use Case Four: You Have Multiple MIDs but Don't Want Your

Transactions Scrubbed on Every MID

iSpyFraud can be used for an entire gateway account, or be customized to only screen the transactions run under a specific MID. In addition, iSpyFraud can also be customized so that any global rules are ignored on a per-processor basis. When it comes to setting different rules for different MIDs, this can be accomplished in one of two ways. A merchant can either set global rules and then single out specific MIDs to have them bypassed by those rules, or set entirely different rules for different MIDs. 1. To start, merchants must have at least two active MIDs boarded on their gateway account, and must be logged in as a user with permissions to all processors. a. When clicking through iSpyFraud tabs Thresholds, User Ban, or Exceptions, the merchant will see a subtab labeled All Processors, then a subtab for each active MID on their account. i. If there are rules that the merchant wants to apply to all MIDs, those rules should be set in the All Processors tab. ii. Any rules that the merchant wants to apply specifically to a certain MID should be set under that MID's subtab. iii. If there are no global rules and every rule is specific to a certain MID, the merchant should not customize the All Processors tab, and instead set all rules within each MID's subtab. Use Case Five: You Process Recurring Transactions and Don't Want to

Accept Pre-Paid Cards

Prepaid cards have their uses, but when it comes to recurring transactions, some merchants may be wary of accepting prepaid cards, as there is a chance that money will run out before the timeframe for the recurring transactions expires. 1. To prevent the use of prepaid cards, the merchant can reach out to the Card Associations to obtain a list of BINs associated with a prepaid cards and enter them under User Ban>>Credit Cards. a. If there are multiple BINs, the merchant can load up to 5000 entries at once into User Ban>>Batch Ban by selecting the Credit Card/Bank radio button. 2. The merchant can also block all cards except for specific BINs by going to User Ban>>Credit Cards and ban/flag cards beginning with the first number associated with certain card brands (e.g. entering "4*" would block all Visa cards). a. Once the desired card brands are blocked, the merchant can go to Exceptions>>Credit Card White List and add any card numbers/BINs that the merchant wants to accept. b. For multiple acceptable card numbers/BINs, the merchant can go to Exceptions>>Batch White List and select the Credit Card/Bank radio button, then upload a list of acceptable cards.