Jason Swenski · CTO and Co-founder, Funraise | This is THE explanation conversation for anyone with protection questions. Listen in as Jason answers all your protection questions with Funraise CEO and Co-founder, Justin Wheeler.

Security should be so good, you never know it's there.

Check your to-do list real quick. Managing anti-fraud protection for your fundraising platform has been on that list since... since you made that list, right? What if we explained everything you need to know about real-deal, got-your-back protection? Here's your best chance to check that important box.

Let Funraise escort you down the transaction fraud protection rabbit hole—we'll shed light on all things security from OWASP to DDoS. Get expert answers to questions like these:

1. How does tough security help nonprofits build true connections with donors?
2. How can anti-fraud technology help nonprofits achieve their fundraising goals?
3. How is the COVID-19 crisis putting pressure on security and protection features?
4. What does my nonprofit need to do to ensure we're covered? How do I know how much support and security we need?

Justin Wheeler Hey, everyone. Thank you so much for joining us today for this very riveting conversation about security and specifically as it relates to fundraising and donor security. Our guest today is a good friend, my business partner and our CTO here at Funraise. Jason is no stranger to security, especially as it relates to technology and software. Jason and I met many years ago, long before Funraise, when we were working together to help North Korean refugees escape out of China and into Southeast Asia. And as those of you watching may know, the Chinese government puts a lot of resources into surveillance and following its citizenry. And so we developed an application, and when I say we, I really mean Jason to help North Korean refugees safely get out of China. And so he literally had to build technology that was for life or death sort of circumstances. And so today we've asked him to come join the conversation around why nonprofits need to take our technology security seriously and what are some of the kind of areas that we should focus on first. And so without too much further background, I'd like to welcome Jason and thank him for being here today. Jason, thanks for joining us today.

Jason Swenski Well, thank you so much, Justin, for that suspiciously terse and grudging introduction. It's good to be here. And thank you so much. If you're tuning into this webinar, we'll be talking about security today. And as Justin mentioned, that topic can potentially be a tedious one. But hopefully, we've put some content together that if you're a nonprofit out there and you're wondering, well, how can you fundraise more securely and in a compliant manner? Hopefully, this presentation will bring some lucidity to that topic. A few more words of preparation, though, although the title of the presentation is Fundraising Security for Smart Nonprofits, the topics that will specifically be covering today are about payments fraud and PCI compliance. These topics are sort of at least ostensibly, tangentially related. But as we dive into the presentation, perhaps I can convince you that they're more intimately related than that. And then just maybe a minor note, a shout out for some of my teammates back at Funraise, I'd like to dedicate such merit as this webinar, never possessed, in fact, to our wonderful systems team, and that it's a team at Funraise who are really the unsung heroes in our fight against fraud, which is a never-ending battle, the tireless one. And they work day in and day out. Developing our sort of tactics and best practices and are just really everywhere all the time trying to keep our customers safe against a never-ending barrage of these different kinds of attacks.

And so fraud is a general word, right? When we talk about fraud, what does that mean? I won't be talking about perhaps today buying your way into Yale by getting your kid onto a soccer team that may or may not exist. And I will be talking about Paige Thompson, who liberated 100,000 account records at Capital One. I think it was last year. We won't be talking about this. But fraud, what I mean today is just online payments fraud. If you're accepting donations online, we're talking about card, not present credit card fraud. In other words, someone using a stolen credit card to get something to get some ill-gotten gains. This phenomenon is on the rise. According to Javelin Strategy, there was in 2018 twenty-six billion dollars lost in credit card fraud in 2018. And, you know, kind of very relevant today as we see the sort of exponential growth in online e-commerce. It's like 81% more probable than in standard POS fraud. A very high upward trend.

Justin Wheeler So a question on that. Real quick, if you don't mind me jumping in. Specifically on the twenty-six billion dollar number. So is this the, is this the cost to the individual? Cause I know that when fraud happens, there's a chargeback. And in some cases, you have to spend upwards of $15 per fraudulent charge. Is that what the number retains to or more so, twenty-six billion dollars of fraudulent transactions happened?

Jason Swenski Yeah, it's the latter. It's just fraudulent transactions. That doesn't sort of take into account the sort of aggregate of like what is the lost time that I spent managing this stuff? Or what is what are the fines or penalties that may be involved and sort of having to mitigate these things? And so it's a problem and it's getting worse. Right? And so you might ask, well, what does that have to do at all with nonprofits right? Nonprofits aren't selling a good or a service. Why is it that fraud is happening? Is there a band of sort of Robin Hood type fraudsters out there that are stealing cards and giving donations to nonprofits? Well, it's really an old scam, right? So it's just it's a new sort of twist. Historically, you have these small dollar transactions happening. Fraudsters would come up with this sort of scheme and they would basically do this to many people and they would just do a test charge and they would set up a fake business or whatever, and they would just bank on the fact that no one cared about $1 or $2 or whatever. And instead of sort of doing that to nonprofits, they just set up that base and then enough people would sort of just not care about it that you'd end up with, as a fraudster, committing these $1 or $2 dollar transactions and funneling it into your bank account from these small businesses. And you do that enough, you could make quite a bit of money. Today, it's a little bit, the twist as well, that doesn't quite work and it's a bit harder to do that. I think the payment space has gotten better to do better verification of individuals and prevent them from sort of saying, oh, well, I'm going to set up a fake entity and route money to it. And so we've evolved and we've said, OK, well, now the scammers are going to steal a bunch of cards and they'll use nonprofit pages to sort of verify that those cards are good by testing and then they'll use it to sort of do something else with that card. So what are the goals of the grifter's? So they want to get a bunch of cards and this is very easily attainable. Right. You can go onto the dark web. You can go and you can buy lists of cards, lists of credit card numbers and then online processors, they want to make a purchase with these cards. And so the nonprofits the deal is, is that if you're talking about e-commerce, nonprofits have the easiest flow possible in terms of verifying your credit card.

There's no purchase that needs to be I don't need to add anything to a card. Nonprofits tend to optimize on conversion only. This is a good thing. Right? You want to make it so it's easiest possible for your donors to donate. And so risk isn't really a factor there in terms of trying to optimize on making sure that your risk is low. Well, how do we get the donation as fast as possible? How do we reduce the barriers and so on? It's very easy then to say, well, that's what I want to use to verify it. Right. I want to go and I want to go to this page. And I just want to be able to very quickly fill these things out and get a response. And I don't care about what the response is. I don't necessarily care if the donation succeeds or not. I just want to know the answer, yes or no. And I don't care if money was moved or not. I just want to know the answer. And so you get there is you get this mechanical aspect of like, well, you have these folks deploying botnets, essentially. Botnets, it's just it's a fancy word for a collection of computers. Right. That's all it is. And so these fraudsters will target nonprofits with botnets. They will just get the batch of cards and try a bunch of them really quickly and they will turn around. And it looks something like this. You just have a bunch of computers and these computers could be collected by a network of malware. So you have a bunch of computers that are infected with malware. You can control them and then you target them as a poor unsuspecting donation page. You just tried a thousand credit cards. OK, good. And 50% of them gave me a good answer. 50% of them gave me a bad answer. Don't care. Going to take the ones that are good. And then I'm going to go do something else with them. I'll go. What most of these things end up resulting is the fraudsters just go buy gift cards. Is the number one purchase out of verification of fraud? Why is that? Well, gift cards easy to sort of launder in a way. Just go and apply it to my Amazon account, or I can go to a store and say I'm good, I'm going to use this gift card. And it's different than the original card. Right. So you've got that level of indirection there. And yeah, this can be scaled quite largely, quite quickly. And you can test lots and lots of cards very cheaply and be quite successful at it. And the tools that fraudsters using, they're not sophisticated. So these are icons. If you're in the sort of software world and you're in the automated testing world, the automation world, you know that this is a fairly easy proposition. It's just off the shelf type stuff that you would normally use to do automated testing of software using something like Selenium, the same tools that you would use to maybe performance test aside for a load test aside or even just automate something for your workflow purposes. Like you just want to automate some tasks that you have to do every day. It's punching some numbers into a website. Same tools can be leveraged to sort of do this verification and testing in this sort of case. And what it looks like from a implementation standpoint, the reason why this is so pervasive is this is such an easy problem, like the tools exist. Literally, if you're familiar or cumbersome with a little bit of code, you can see here that you can do something like this. This is a mock. This isn't real, but it wouldn't be much more complicated than this. You would just tip the page, fill out a bunch of information, send the credit card. Do I get a good response? Do I get a bad response? Just looking for what text appears on the screen and so on. And so, well, what can we do to stop it? There are several things and I think there's a lot of misinformation out there, right, that there is a lot of sort of maybe naive methods or really simple methods. There are some very complicated methods. I will say that I think, as I mentioned in the beginning of the presentation, I dedicated this presentation to the systems team and it's rumored internally that our head of systems keeps a 2x4 and a pair of pliers in her desk drawer.

And they know if we could maybe somehow solve for the location of finding out what the fraudsters were, mitigation strategy could be had that maybe wasn't so technological, given that this is a problem that she has to face every day and a team has to face every day and we get very, very annoyed at having to stop it. But nonetheless, we'll be talking about the technological solutions. And so there's several. And I think you could probably broadly categorize these techniques into two to sort of buckets. There's the rules-based approach. And those the ones that if you go to Google, how do I stop fraud on my donation page? You're gonna get probably a list that looks something like this. They're very mechanical variables based very well, if I find a donation and it comes from a bad IP, we should block the IP. Or, I notice that there are lots of small donations, so I need to configure my donation form to have sort of minimum amounts, maybe well cap it at $5. I can tell you that this doesn't always work. We've seen fraud ranging from small dollar amounts all the way up to very large amounts. And the reason for that is to sort of circumvent what nonprofits will typically do. This is a very easy thing to do, is configure minim amounts. And fraudsters will react very quickly, especially with these large networks of computers that are just sort of deciding, well, let me vary the amount to make sure that we're not getting caught up in one of these rules. The gateway level rules, right? Usually, if you're processing a line, you have a gateway and you have access to these rules. There's the AVS checks that you can do, which is verification of the address for a particular credit card. And there's the CVV in the CVC rules, too, right? And these are just the standard gateway rules that are like make sure that the three-digit card is there... or the three-digit number that goes along with cards. Again, kind of going back to nonprofits and how this can be diametrically opposed to what they're trying to do this they're trying to get donations in as fast as possible. Anything that affects conversion is usually something that maybe you want to stay away from. Maybe we don't want to have the user enter in their billing address. Because this could be this is an extra step. It's an extra barrier. Or perhaps we know that lots of people, it's legitimate when they get the CVV wrong, maybe they just typed it in wrong. And so I don't want to lose a donation because I have someone frustrated because they mistyped an extra set of numbers. It's unfortunate because quite frankly, this would mitigate lots of fraud if people turn these features on, because the lists of credit cards that are purchased usually very sparse and information, they don't include all of this. And so you'll see when fraud testing happens and you'll see the numbers come in maybe correctly. But it's just the information is just all random, whatever, because they don't the fraudsters don't have access to all this information. So if we just turn these rules on, it might help quite a bit. And then there's some other rules. There's content filtering. You can check IP against location. You can do device fingerprinting. Some or all of these may be supported by your particular software and you maybe have some of this implemented on your site yourself. But they all suffer from the same problem, essentially. And that's, they're rules-based.

They're very much reactive. You have to sort of tune them then fraudsters can say, ah, fine. I'll get the addresses. Or, ah, fine. I'll vary the minimum amounts or I'll just use a different set of computers and vary my IP and location. So if you ban one reason or if you ban a block of IP is they can just get new ones very cheaply, especially today. And so that kind of takes us to the sort of second set of buckets, and that's behavior-based type fraud mitigation. And so there's certain flavors of CAPTCHA. So Google reCAPTCHA, for instance, is sort of a behavior-based model. CAPTCHA can solve a lot of problems. There are some downsides to CAPTCHA, too. Obviously, an argument against CAPTCHA is, again, the conversion aspect of requiring donors to do a different thing. In addition to the donations, you can get false positives of CAPTCHA which make donors solve the lovely problem of identifying all the penguins with top hats, for instance, in a picture or whatever. And that can be quite annoying, especially if it's legitimate. Other newer flavors of capture which are better. These are things that we internally are very excited about that are just risk scoring. And they're actually there's no intervention. There's no sort of friction for the donor at all, for the user experience. There's no CAPTCHA on the page. They don't have to take any action. And those are interesting. But those also require, you know, probably some good modeling, probably some analysis on, well, where do you want to finally tune these thresholds? And then there's things like Stripe Radar. So Stripe Radar as a behavior-based sort of fraud mitigation technique.

It's machine learning-based all avoid using the term machine learning, because I know people get quite sick of that, having just machine learning thrown around as a buzzword at the panacea for all things. But basically it's a very well-designed machine learning model and it leverages sort of just a huge volume of the Stripe network. And it learns very well about what things look like fraud and what things don't look like fraud and essentially what these things do, machine learning type models that just take into account lots of different sort of features or lots of different sort of data points for a particular type of donation. And lots of the data points, in fact, from the first set of things that we talked about in terms of like IP or amount's and so on and so forth. I'm not going to talk too much, but Stripe Radar, because if you want to know about Stripe Radar, they have pretty good marketing materials. Look at it and Stripe Radar, of course, works in the case that you're using Stripe, which, as you know, with Funraise, that might not necessarily be the case. Funraise was designed to be sort of payments processor agnostic. And we have many customers that are using Stripe Radar as a sort of this model and sort of this broad mitigation technique. But we have customers that are using Stripe as a gateway and many other gateways to support other countries or payment instruments or currencies. And we released a really cool feature recently to be routing based on certain data points of donation. So we've suffered this sort of situation that's just industry-based for a long time, trying to be a vendor. And the online fundraising space allows you to choose. To bring your own gateway, to have many gateways, to have a situation where you offer all the payment methods and leave a donor no real, you don't disqualify your donors, in other words, but by what payment methods, or currencies you offer. You offer them as much choice possible. And so that means supporting many gateways. And we've worked very hard to support many different gateways here internally at Funraise. But the problem has always been, well, there's a huge disparity between the fraud mitigation sort of techniques and fraud mitigation strategies that different gateway support. And it's sort of fallen on us to sort of make sure the playing field is level in a way between all of them. And so we worked hard on building up this new feature, which I won't spend too much time here on. This isn't really supposed to be a sales pitch at all. And out of caution of sounding too huckster-ish, I won't spend too much time on just talking about this feature. But it's an interesting feature. And it's it's one that we're quite excited about internally at Funraise, and that's our advanced fraud protection suite of software. And so what that is, is it is a layer in front of all gateways that sort of gives you a common denominator of fraud protection. And it's built using machine learning models. We partner with industry experts to sort of integrate this into our stack. And again, you get that sort of really sophisticated, really advanced machine learning type models that can respond and learn and tune sort of dynamically instead of you having to go and say, well, this region or that region or this IP or that IP or this minimum amount of this, this minimum amount. It's constantly learning and constantly deciding based on many different dimensions and many different relations between donations and data that are very hard for a human to sort of reason about. We allow this to be the case across many different gateways, regardless of what you're using. If you're using Stripe, great. If you're using Stripe and World Pay, perhaps using World Pay in a different country with a different currency, that's fine, too. And so we're pretty excited about that. We're pretty excited about how it will provide a level playing field for fraud mitigation across all the different gateways that you might bring to our platform.

So, that it kind of takes us into the second bit of the presentation here. And that's PCI compliance. It's a related topic. What is PCI compliance? It's it's the compliance aspects that that cover credit card processing online that every organization, if you're accepting credit cards, you have to adhere to PCI compliance. Now, this is not obviously related to fraud, but I'll say this. It's related to fraud in the way that these regulations sort of layout how sensitive data is supposed to be stored and how credit card data and PCI scoped fields should be protected and the strategies and the things that you need to do to make sure that that's the case. If everyone followed these regulations, well, we wouldn't have as many data breaches and credit card breaches as we, which is the vector in the first place for the fraud that we talked about in the first part. So that's kind of how these things are related. And then secondly, this is just a question that sort of comes up all the time because, again, there's so much bad information out there. What do I have to do to be compliant? You know, what is my organization responsible for? What vendor can I use to make sure I minimize that burden? And so kind of in short, pretty much everybody has to.

Everybody is responsible for PCI compliance. Most organizations kind of don't do this correctly. A lot of organizations come to us and they don't know what SAQ-A is. They don't know that they are a merchant. Right. They have a Stripe account. They have a merchant account and they need to, in fact, do a small amount of paperwork. Especially if you're with a vendor like Funraise, which minimizes your PCI scope. But it's not always the case, right. The scope can vary quite a bit depending on what vendor you choose or whether or not your vendor is actually doing the correct things and being compliant themselves. So, yeah, I'm sure all organizations, if you're accepting card present or card not present transactions online, you've got to do some amount of paperwork and hopefully not copious amounts of paperwork. You want to end up in the SAQ-A bucket instead of the SAQ-A-EP bucket, and you can read all about these kinds of things that the PCI standards sort of completing the self-assessment thing on the slide here, it's linked. And then, your vendors that they need to be SAQ-D or better. And additionally, if you're using a gateway, you want to make sure that it's also PCI comply, that's more likely because that's very much you can't work with banks if you're not PCI compliant. But I think there's a lot of sort of intermediate type payments facilitators that sort of script the rules and they facilitate the payments, but maybe not go through all of the particular hoops that it requires to sort of be compliant. So this is just kind of a picture. This is like five years ago when we're talking about starting Funraise. We looked at this problem very heavily and we're like, well, what's a way that we can architect ourselves to make sure that we minimize the PCI scope of our customers? This is SAQ-A-EP. The longer one, if you're a merchant. You don't want to do this. This is like 50 pages of pretty tedious questions on firewalls, on controls, on security policies and managing all these things and so on and so forth. And it's it would not be a fun exercise, depending on what software you're using to have to build something like this out. And again, there's no such thing as covered by your software.

A lot of the weirdness comes in, especially with on-premise type situations. If you're on-premise, you want to understand very much how that credit card information is being stored, if it's being stored on-premise or if that information is passing through your servers on-premise, you might have a high burden of compliance. You might have to fill out a much longer document and have to be subject to any more regulations, such as quarterly vulnerability scams, you know, audits and so on and so forth. And it's a very high cost to not being compliant. So PCI is not a legal stipulation. It's a sort of if you want to play in the credit card space, there's the PCI Standards Council, which is a sort of consortium of credit cards and banks and so on. They get together and say, here, the regulation, you have to do it. And if you don't, we can do a couple of things. We can find you and we can penalize you and they might fine you not by saying you need to send us a check for $10,000, but they might increase your transaction fees. They might sever the relationship that they have with you as a processor. There could be just sort of legal action taken if you're not PCI compliant and the breach happens and your donors get mad and end up suing and so on. And these fees, they're not typically published, but they can be quite high. I've seen things such as like $5,000 a month or $100,000 a month until the merchant, in particular, is compliant. These are costs that could very easily put a small nonprofit out of business. And so it's very important as a nonprofit to sort of be sure of your vendors. Again, everybody is responsible for PCI compliance. You really should try to be in that SAQ-A It's a very short document. Just saying, yep, we don't accept credit cards and write them down or store them or anything like that. If you're using any sort of same software. Not doing this right. You're just accepting it online. You have to say that you're fully outsourcing your credit card processing and you know that the vendors that you're using are PCI compliant. You list the vendors that you use for online fundraising on the documents, maybe 10 pages maximum and mostly it's fluff. it's just filling up who the organization is and so on. It's very short. You want to be in that category.

And just sort of I think that some statements you get, this is easy to find out. Just Google it. Just Google the vendor and their stance on PCI compliance. I did a couple of these. Woo Commerce is I know, a piece of software that people will tend to use for online fundraising. And you can go and you can find directly in their documentation. Woo Commerce is not PCI certified software. It's well written. Right. It's written with security implications in mind and so on and so forth. But there is quite a bit of burden here. If you use Woo Commerce, since it is not PCI certified, you have to fill out quite a bit more stuff to say that, yes, we're using it, but additionally, we meet these stipulations and here's why. You keep your servers updated. Maybe you have to do the quarterly vulnerability scans, an independent party and so on.

Here's Blackbaud's stance. Blackbaud is another big player in the space. And they say quite clearly, I think because we have here, too, it's the responsibility of each Blackbaud customer to comply with PCI, DSS as prescribed by the PCI Security Standards Council. And so I think these two messages, at least for these two vendors, are, I think, some of the most clear in that. Yeah, everybody's responsible. Some vendors will maybe not be so clear. And I think here's a sort of a sketchy one that I've seen from another well-known I won't name them vendor out there. And on the topic of PCI compliance, if you just Google if this vendor is PCI compliant. And they'll say, yes! We're PCI compliant under SAQ-A and we use Stripe Elements and we're powered by Stripe and therefore everything is fine. Well, it's not quite. Because if you're using this vendor, at minimum, you should be doing some burden of PCI compliance, which is filling out SAQ-A but SAQ-A doesn't cover this vendor. They're a service provider. They're facilitating the payment. They're involved in the transaction so they themselves should be stating, are they PCI certified right? What audits have they done internally? What things or are they sort of doing? Do they have an independent assessor making sure that they're adhering to these things? Because if you use them and they are not the burdens on you right? Because in your SAQ-A document, you need to say that you're using PCI certified software to do online transactions. I've heard this one before from customers that have come over to us during the sales process. It's "yes, we have all the security." They'll buy the software and then end up with an audit or other end up with something, some fraud or something like that. There's a bunch of questions from Visa or the banks or so on, and they'll go back and they'll say, "oh, the vendor will say, oh, we misunderstood the question." Or "maybe we weren't quite PCI compliant." So get it in writing. You should be able to validate these things, check them, you know, ask for something like this, you know, Funraise. If you asked for PCI compliant, we can give you a thing that says, yeah, we're compliant and we can tell you who are QSA is and who's done our audits and who does our quarterly vulnerability scans and so on. And so hopefully with all of that kind of sort of convinced you about some of these topics, tedious as they are, and that there are some major benefits to taking this stuff seriously, even though it can be sort of hard to reason about, you know, sort of, again, tedious. Here's the thing, though, like most owners today, there is a level, there's an expectation for what a donation page looks like for treating your data security. The advent of GDPR and other regulations in other regions. I mean, this is sort of just part of what's top of mind for individuals today. Everyone out there, I guarantee you, you've probably been part of some kind of a credit card breach or some kind of a, some sort of a situation of that nature. So it's very much top of mind. If donors feel safe, they're going to get more and they're going to get more often. And this is going to save you time and money. Avoid the penalties and the fines of chargebacks. This is the chargebacks thing that's even outside of the fines. Right. So for every fraudulent donation that you get, it could be a fee of $15 to $25, I think, as Justin mentioned earlier in the presentation. Those can stack up quite a bit. In addition to the fees and then know your vendors, make sure that you're using something PCI certified. Make sure that you're using something that is limiting the scope of what you have to do. And your vendor should be able to tell you this, right? You don't, you don't want to have to fill SAQ-A-EP if you don't have to. You don't want to spend that time. You want to say the least amount of work possible. You don't have to want to have any of the ill effects of sort of dealing with a vendor and going through an audit and then finding out that they're not PCI compliant. And so that's kind of it. Hopefully, you feel a little bit more informed about credit card fraud and compliance as it relates to online fundraising and hopefully, you feel a little bit better about, a little bit more versed in some of the common mitigation strategies that are out there and what to look for in a vendor. And that's just sort of a former nonprofit practitioner, I know these topics can be overwhelming. And so if you have any questions, just feel free to drop me a line. It's jason@funraise.org and ah yeah, stay safe out there.

Justin Wheeler Jason, thank you so much for that presentation. Honestly, it got me fired up to find and track down these fraudsters and bring them to justice for their misuse of stolen credit cards, among other things. But in all seriousness, thank you for walking us through the importance of detecting fraudulent transactions, as well as being compliant from a PCI level to create more trust with your donors. Maybe the first question I'd like to jump in and ask is for organizations that are using something like Stripe Elements, which, as you know, is its machine learning model to detect fraud. Where does Funrise coming into that equation? Do we? Do we add another layer to that? Do we become redundant? What are some of your thoughts around sort of the extra security that we provide from the Funraise, our fundraising software perspective?

Jason Swenski Without having to make too much of a direct comparison to Stripe's product? I mean, it's a very good product, right? They obviously have lots of data. It's a big network. They do fulfill sort of similar use case. I think it's beneficial. It's an extra layer of protection in each case. So that's good. I think where it really shines again is where if you're using Stripe and Stripe alone and you're just doing credit card payments. That perhaps you could get away with saying I will fundraise and hence fraud protection thing. Maybe yes. Maybe no. Maybe I don't need that extra layer of protection, in other words. But as soon as you start talking about different payment instruments, maybe you're talking about Bitcoin, maybe you're talking about PayPal, maybe you're talking about ACH transaction, Our fraud protection covers all of these things additionally, additionally, as soon as you start talking about maybe you want to add another gateway into the mix in Funraise. Which has a lot to do with one of the few sort of payments platforms that allows you to bring your own gateway to do any number of them and to, in fact, dynamically route your payments depending on certain rules like currency and so on. Funraise is sort of common denominator of fraud protection because you only get Stripe Radar if you're using Stripe, and that's only relevant to Stripe. And although it's quite good, there's a lot of different payment solutions out there, a lot different payment mediums out there. We have lots of organizations that are in that category. And so that's obviously the reason why we did that is like not everybody is Stripe, right? So we have to provide some sort of common layer of protection if we're going to say anybody can use whatever they want.

Justin Wheeler Got it. Thank you. Another question comes to mind, and you talk about this a little bit earlier in the presentation. Often what you see at nonprofits, it's a dance between ultra-secure and optimization. And if I'm on the marketing team, you know, I want the slickest least friction way to make a donation if I'm on the, you know, technical team, I.T. team, security team, I want to ensure that security is top-notch. And often these things can conflict with one another. So what's your advice as someone who obviously understands the importance of both elements? What would your advice be to organizations that are trying to find that balance between optimization and security?

Jason Swenski Yeah, it's a good question. Unfortunately, what you end up seeing a lot of the times is kind of this very depressing valley between the two, right. Where it's whichever team is more vocal or stronger sort of gets their way. And so you either have a donation page, that is incredibly long, requiring all the things and this is particularly ugly, or you get something that is very clean and very slick with no friction at all, and you end up with lots of fraud or the potential risk of lots of fraud. And it's never a happy medium in between. I would say just based on my where I sort of lean in it, it's I'm going to lean a little bit more on the cautious side. I'd say that's probably more of a personal preference than a strategic one. If anything, I'm just made in that way. Now, I would say that there's probably good arguments to say, well, you should have some of these things. Like reCAPTCHA is a good example of this, right? It's really not that fractioning and it's probably false economy to turn these off. CVV checking... also, maybe one that is, yeah, you could argue that you might have some fraction of a percent of conversion loss if you turn it on. But the benefits clearly are there. The things about AVS checking whether or not, you know, you should have like a bunch of other rules and things, it's hard to say. But I think that's where really these tools like Stripe Radar and our enhanced fraud protection here at Funraise that's in beta. By the way, if you're interested in the beta, and you're a customer today, contacts CS (Customer Success) and get on the waitlist for that because it's a really cool product. Those are where those shine. Because you can have your cake and you can eat it, too. And those you know, it's just curve fitting. It's just mathematical models that are tying in a bunch of inputs together really quickly and doing these sort of rules-based thing in a much more quick and intelligent way. We could historically very fast without the friction right there, just taking inputs and doing what we want without sort of interfering with the donor. So, maybe that answers your question.

Justin Wheeler Yeah. It totally does, and I think there's you know, there's two ways to also look at this, right? We're talking about fraudulent transactions. And, you know, there is like this I think there's a healthy dance between, you know, having a safe and secure giving form that's optimized when it comes to PCI compliance, this is where I think the hammer really needs to get dropped because protecting donor information is and should be, you know, of the utmost concern to an organization as it's raising and scaling online and so ensuring their own compliance, ensuring their vendor's compliance. I think that is very well-noted because you don't want to be the next, you know, organization that was exposed and leaked all this sensitive data. And so I think that's something that as I kind of listen to the talk, that's an area where we really focus a lot of my time to ensure that it doesn't happen to, and we have the right protections and protocols in place. With that, I think we're going to we're gonna wrap it up. And if people have questions ah you shared your email address, which will ensure we will also make sure to include in sort of the on the page as well. People can get in contact with you. But, Jason, thank you so much for spending the time with us today to educate us on the importance of security as relates to fundraising and donor privacy. And we look forward to the conversations down the road on this very topic. Thanks, Jason, so much.

Jason Swenski Thanks for having me.

This podcast is brought to you by your friends at Funraise. Nonprofit fundraising software, built by nonprofit people. Don't forget to get your next episode the second it hits the internets. Go to nonstopnonprofitpodcast.com and sign up for email notifications today. See you next time!

‍