Fake Accounts

Hi Jason,

We had a similar thing happen to one of our consortium organizations a little over a year ago, so I feel your pain! The fraud event resulted in almost 8,000 records with dummy emails and address info and approximately $2,500 in small fraudulent donations. It was essentially a credit card testing scheme that exploited the org’s low minimum contribution amount on one of their donation pages.

Everyone's suggestions so far sound right on the money. We enforce reCAPTCHA in all available locations on our org’s TNEW sites, but somehow, they were able to get around it for some transactions. I forget the exact numbers, but if that wasn’t configured, we could have easily seen double or triple the number of fraudulent accounts created, so it’s definitely good to have that in place.

Here are the broad steps for what we did in terms of cleanup:

1. Identify all fraudulent records created. They all followed a similar email format, so this wasn’t too hard. We used a combination of some list pulls and reporting (New Record Summary, and On Account Tracking, etc.). The goal is to end up with one list of all fraudulent records created during the event.
2. To prevent further activity on these records, we quarantined them by inactivating them with a “Fraud Record” reason. We only did this to give the org time to deal with all of the refunds they had to process, so it may not be necessary in all instances.
3. Once any fraudulent transactions were delt with, we scheduled the records for purging and tried running the Purge Constituents Utility. We did encounter sluggishness and some blocking when running the utility from the front end (even on a smaller batch of 10 records). We asked the Network about it and they suggested running from SSMS. I believe they can even provide a stripped-down version of the procedure that should run faster, so I would reach out to them if you encounter similar issues.
4. This step hasn’t happened yet, but eventually these purged records will be picked up by our merge process and merged into our General Public record, so they don’t clutter the database. We schedule about 100 records for merging into the GP record weekly, so it’s going to be a little while until we are finally rid of them. In the meantime, they aren’t usable and are clearly marked, so they aren’t hurting anything.

Hi Jason,

We had a similar thing happen to one of our consortium organizations a little over a year ago, so I feel your pain! The fraud event resulted in almost 8,000 records with dummy emails and address info and approximately $2,500 in small fraudulent donations. It was essentially a credit card testing scheme that exploited the org’s low minimum contribution amount on one of their donation pages.

Everyone's suggestions so far sound right on the money. We enforce reCAPTCHA in all available locations on our org’s TNEW sites, but somehow, they were able to get around it for some transactions. I forget the exact numbers, but if that wasn’t configured, we could have easily seen double or triple the number of fraudulent accounts created, so it’s definitely good to have that in place.

Here are the broad steps for what we did in terms of cleanup:

1. Identify all fraudulent records created. They all followed a similar email format, so this wasn’t too hard. We used a combination of some list pulls and reporting (New Record Summary, and On Account Tracking, etc.). The goal is to end up with one list of all fraudulent records created during the event.
2. To prevent further activity on these records, we quarantined them by inactivating them with a “Fraud Record” reason. We only did this to give the org time to deal with all of the refunds they had to process, so it may not be necessary in all instances.
3. Once any fraudulent transactions were delt with, we scheduled the records for purging and tried running the Purge Constituents Utility. We did encounter sluggishness and some blocking when running the utility from the front end (even on a smaller batch of 10 records). We asked the Network about it and they suggested running from SSMS. I believe they can even provide a stripped-down version of the procedure that should run faster, so I would reach out to them if you encounter similar issues.
4. This step hasn’t happened yet, but eventually these purged records will be picked up by our merge process and merged into our General Public record, so they don’t clutter the database. We schedule about 100 records for merging into the GP record weekly, so it’s going to be a little while until we are finally rid of them. In the meantime, they aren’t usable and are clearly marked, so they aren’t hurting anything.

Thank you so much for this. I/we greatly appreciate you and everyone else's time in helping us out with this.

-Jason