Gusto launched in 2012, and in the years since, it’s built a reputation for bringing elegant solutions to payroll, benefits, and workers’ comp. The company has also created the technology and culture to support those efforts, taking the team deep into the weeds of the ACH network and beyond.

Recently, the co-founder and CTO of Plaid, William Hockey, chatted with the co-founder and CTO of Gusto, Edward Kim, about everything from using ACH, fighting fraud, and building payments companies. The following interview has been edited for clarity and brevity.

WH: Gusto has been working with bank payments for years. What are some of the biggest things you’ve learned while scaling your payments on the ACH network?

EK: Honestly, I think the biggest thing was just learning how it worked, in particular the returns and error codes. That was something that was a total black box. It’s hard to read a 400-page booklet and understand the practical implications. And it can get pretty complicated, especially when you get into fraud and returns when people call in and say, “I didn’t authorize a transaction.” That’s something that’s been a piece of learning for us since we started this.

WH: ACH has a ton of obvious positives: It has massive market adoption and it’s inexpensive. Are there any other major reasons that Gusto moves money over ACH, and have you ever explored other options? Like moving over the debit rails, utilizing some sort of crypto-currency, or anything like that?

EK: We’ve definitely looked at some alternative ways to move money. One thing we thought about was bitcoin. I would say two or three years ago, around the time that bitcoin was quite popular, we started talking about actually paying people through bitcoin if they wanted it. A lot of the engineers got really excited about this, because it was a popular thing back then, and we could move money very fast, and it would be free, and it wouldn’t have many of the hindrances that ACH came with.

Fortunately, before we actually started developing, we took a step back and we said, wait a minute, let’s think about this. Do our customers really, really want this, or is this just something that we want in our product? And we kind of came to the conclusion this was just something that we wanted. We also talked a lot with our sales and our customer support team, who gave us similar feedback, and we ultimately decided to pull the plug on that.

So I would say that was kind of our first foray into looking at alternative payment methods outside of ACH. We’ve had a lot of high-level discussions about other options more recently, things like debit rails or intra-bank transfers.

We would love to someday have a zero-day ACH payroll run, where you can run payroll and then see money in your account just a few minutes later. That’s something that doesn’t really exist yet. It doesn’t even exist in the payments world. When you take cash out from PayPal or Venmo, it takes a few days to get the money.

WH: To dive into that further, the transaction lag in ACH is well known. I’d imagine most people probably budget around their payroll date, and so getting money into their accounts seems like one of the biggest priorities Gusto has. How have you worked to speed up the process?

EK: We started with four-day ACH, which means that from the time that a customer runs payroll, it takes four business days for the employee to get paid. We’ve moved some of our companies—not all, but some—to a two-day ACH program, which basically cuts that delay in half.

Essentially, we do the debit on the company’s account to collect the funds for the payroll and the taxes, we wait one day, and then on the following day we’ll do the credit to the employees, and then the employees will get paid on the day after that. So that’s two days from the time that the company runs payroll.

That has some risk to it, because it can take up to three days after we debit the company for us to really feel a high degree of confidence that that money is good. And in some cases we actually do hear back three days later that the money we tried to pull from the company is no good, or the company didn’t have enough funds in their account. But by then, of course, we’ve already sent the funds to the employees.

That’s the kind of risk that we take on when we try to shorten the ACH window for payroll. And so that obviously involves some kind of underwriting.

In those cases, we have to look at the company, and say, “Does this company have the creditworthiness for us to trust it and take on that risk?” And if we deem that the answer is yes, then we’ll be able to offer the two-day program to that company. But if the company is on the riskier side, we may require that company to be on four-day ACH until it has built some more trust with us.

WH: Totally makes sense. There’s also obviously that 60-day lag, where consumers can go back to you and try to claw that money back. How do you prevent that from happening?

EK: When that happens, it’s really hard for us to get the money back. We are often stuck holding the bag, and we have to write it off as a loss. So the best strategy is to just not let it happen in the first place.

We have invested a lot in our fraud detection system. We call it ZenSA, and it essentially takes a lot of inputs and makes a call on whether or not a company should be one of our customers or not. It’s a combination of software and human effort from the people on the risk operations team.

There’s also an ongoing monitoring aspect. We’ve learned this the hard way, but just because someone is part of our system doesn’t mean that they will always be trustworthy. We can have things like account takeovers, or there could be someone who’s really, really clever and able to get through our system, who starts misbehaving once they’re in the trusted zone.

So our fraud detection system also continuously monitors these companies to make sure that they’re not doing anything fishy after they’ve been accepted as a customer.

By doing this, we minimize the number of incidents where we get the 60-day return from a payroll run, and we effectively reduce our fraud loss.

WH: Is the majority of fraud accidental, kind of like friendly fraud, where good people just go out of business? Or have you seen an upsurge in money launderers actually using the payroll system to defraud people?

EK: It’s interesting, because when we were first getting started, we heard a lot of stories about companies going out of business that want to pay all their employees as much money as possible on the payroll company’s dime. But we haven’t actually seen it too often in our system, at least so far.

We definitely see the second case. A common attack vector is a fraudster who steals bank account credentials and is able to verify test deposits or do the online identity verification. Then he runs payroll and pays himself as an employee—using someone else’s account, of course. And he’s often using bank accounts on the employee side that have little identity connected with the actual fraudster. You also see a lot of fraud going through prepaid debit cards, where you need little to no information to obtain a bank account number. So that’s the fraud vector that we see, I would say, most of the time.

WH: One of the things that we’ve seen people have issues with, and you actually mentioned in one of your blog posts, is how you differentiate between business and personal accounts. I know it’s pretty important in the ACH system to differentiate CCD from PPD in the batch header files. Do you know why that’s the case?

EK: The main difference is that the 60-day return for fraud doesn’t exist in a business account. So if you debit a company, you use a CCD code, and if it turns out to be fraud and you’re notified, say, 10 days later, you’re not liable to give the money back.

For a consumer account, it’s much more consumer-friendly, obviously. For a corporate account, it’s a little bit more strict.

Obviously, we much prefer to send ACH debit using the CCD code, but not everyone sets up their company using an actual corporate bank account. Many use their personal accounts for their company.

WH: Got it. And do you pretty much just leave it up to the employer to determine whether it’s a corporate or personal account, or do you get some acknowledgement from the bank?

EK: We code them all with corporate account entry codes, so we always send CCD. If the bank determines that the receiver is actually using a personal account, the bank will automatically downgrade the ACH entry to the PPD code.

WH: It’s clear that you take user trust really seriously. I’m wondering if you can explain a bit why that’s so important, given the space you’re operating in.

EK: There’s just so much information that we’re trusted with, and out of necessity, we created a culture that takes this really, really seriously. On top of that, the volume of money that we’re moving is massive. I think people kind of forget that payroll companies are, at their foundations, payment companies. So having good security and being really protective of this information is very important to us. I think that’s something that we realized from day one, and we have really built that mindset into our culture.