As we enter the final stretch of 2022, founders are confronted with a double whammy of fraud as two well-known industry trends converge. The first is that recessions tend to increase incidents of fraud, as more people have the rationale, motivation, and time to commit financial crimes. The second is that more people commit fraud when commerce spikes (typically associated with the holiday season) as they hope that they can slip under the radar given increased transactions, distracted sellers, lower staffing levels, and holiday-related company closures.
With these dual trends, founders should be thoughtful about fraud and how they can both prevent and react more quickly to it. The good news is that there are more tools than ever out there right now that are right-sized for startups. The challenge is that these tools may still be too sophisticated for early companies, and/or there are still vulnerabilities at a foundational level that can leave companies exposed when they think they have sufficient protection. What’s important is to think about the tradeoffs and investments related to mitigating fraud loss, which typically come at the expense of customer experience and growth. I learned many of these lessons the hard way as the Co-Founder & CEO of Azlo, a digital banking platform for small businesses. Here, I outline some of the basic “gotchas” that early-stage founders face when it comes to fraud, and how they can more easily reduce their vulnerabilities in these areas.
Gotcha #1 - If I put in the right vendors, I’m safe from onboarding fraud
As you develop your onboarding flow, you may have all of the best tools at your disposal to address critical pieces of the fraud and identity stack: KYC, ID verification, geotagging. But all of this sophistication is tied to the identity used to open the account. One critical piece of onboarding is to verify that the identity of the applicant is also tied to the person in front of the computer applying for a service.
What we have seen again and again is that there is a data breach at a financial institution, or someone’s credentials are obtained in some other nefarious way, and a fraudster will use that legitimate information to open an account. This is called third party fraud. If you cannot tie the actual person applying for an account directly to those credentials, you have exposed yourself to the potential for massive fraud through ACH/ account linking, credit risk, etc. despite perfectly validating all of the provided information.
Often the easiest way to do this is by sending a one-time-passcode (OTP) through the phone - thus linking the individual holding a physical phone to the account credentials. Here, it is important to ensure that the phone number is associated with a third-party record to the individual, and it is not a VoiP number. We’ve also seen fintechs use selfies/ liveness tests and restricted account utility until something physical (i.e., a card) has been mailed to the official address on record. Across all of these, the tradeoffs will be ease and speed of account onboarding and fraud. In my own startup, we chose to have a risk-tiered approach, where we required an SMS-based validation code for everyone, and we added more friction for accounts that we had less confidence in.
Gotcha #2 - Identity holes only exist at onboarding
One mistake I see is that a company may fix the “person-in-front-of-the-computer” identity issue at onboarding, but they don’t think about it across the full lifecycle of an account. I think (hope?) given the challenges of account takeover that most companies today institute some sort of device fingerprint and/or multi factor authentication for login. However, holes here still exist. Pay particular attention to demographic updates, in which case an imposter can completely change an address (and thus card mailings) to a new destination without any sort of validation, and in some cases through a call center. In general, ensure there are notifications and redundancies built in whenever a demographic update is made, and require all account changes to occur within a logged-in session (as opposed to letting call center agents make those updates directly). As you map out your vulnerabilities, think about potential points of failure at all points of engagement with a product, including social engineering attacks.
Gotcha #3 - If I have transaction limits, I’m protected from fraud losses
Limits are a well-known fraud mitigant, but they need to be done right. Even if founders have some limits built in, many of these strategies are not thorough enough – and fraudsters will systematically test these boundaries on new products. I still remember the time at my startup where we set per transaction and daily limits- but we failed to set weekly/ monthly limits and quickly lost tens of thousands of dollars in ACH returns from one bad actor who ran through a series of combinations until they found our vulnerability. First, ensure you think through limits across multiple vectors: per transaction, over time, and how limits aggregate across multiple transactional methods if you have them. Second, think about limits as part of a broader tradeoff between customer experience and losses. Ideally, you’ll want to have limit tiers that a user can “graduate” from as you have more data and can better risk rate them. Don’t overly restrict fraud to the point where you have a punitive product experience for all customers.
Gotcha #4 - If I’ve got Third Party fraud under control, I’m all set
A lot of these techniques are about plugging holes in third party fraud- when someone gains access to another person’s identity and initiates transactions without their permission. Another type of fraud is first party fraud - when someone commits fraud using their own identity. Often we think about it being associated with lending; however, it is also recurrent among non-lending fintechs and is likely on the rise in the face of macro challenges and a fintech ecosystem that doesn’t have strong “bad actor” databases. A common form of this fraud involves debit card or ACH disputes that they claim were a result of stolen credentials. The best way to prevent this is to integrate vendors that share data - especially if they can incorporate EWS data. EWS (early warning system) is an inter-bank database of bad actors where you can determine before onboarding an account whether they have had their account closed elsewhere due to fraud or financial crimes. This type of fraud can frustrate founders and catch many by surprise who think they have taken all of the requisite steps to mitigate fraud. Most small-time fraudsters aren’t worth law-enforcement’s time, and many hop from company to company repeating the same tricks with legal impunity.
Beyond these basic “gotchas”, fraud is a constant game of whack-a-mole. Fraudsters always manage to stay one step ahead of systems, vendors, and rules, and it is important to ensure there is someone tracking what these are so you can update your prevention techniques. For example, one of the most recent schemes I’ve heard about is criminals in the southeast jam ATM openings and are able to access the money that is disbursed; however, the machine reads the opening as broken and doesn’t actually debit the account. Free money. Someone should be watching for unusual behavior and understand what is going on; then the broader team can debate the tradeoffs between losses and growth/ customer experience and make a calculated decision about how aggressively to address the issue. But if you aren’t watching as a first step, these bad actors can easily slip under the radar.
A few final high level thoughts:
Here at Restive Ventures, we combine early capital to fintechs with the operational know-how to help address many of the fraud (and other!) issues founders face as they launch and grow their businesses. If you’re an early fintech founder, we’d love to hear from you!