Sam Quigley leads the Security and Risk team at Square, where he’s been for nearly seven years, after working in information security at a number of different startups. But his interest in financial services security has been with him his whole life, and it’s an area where he thinks there’s a real opportunity to have a positive impact. Here, Plaid co-founder and CTO William Hockey chats with Quigley about balancing usability with security, fighting the biggest threats facing financial services, and building a security-conscious company culture. This interview has been edited for clarity and brevity.
WH: What does your current role as Risk and Security Lead at Square involve?
SQ: I lead the Information Security team and the Risk team. Both sides of the house are worried about similar things. There are a lot of bad things that could happen to a company, and we try to stop that from happening to Square.
On the security side it’s mostly about the long-tail risk: very unlikely events that would have a very big impact on the company if they were to happen. We protect against data breaches, and we build protection into our hardware and our software to make sure that our customers are safe when they’re using it. It’s mostly an engineering discipline at Square, which is different from a lot of companies.
On the risk side, we’re also worried about bad things that might happen to the company, but the risks there are much more common. There are fraudsters every day, and we have very sophisticated systems in place to detect their activity and knock them out of the systems as quickly as possible.
WH: You’ve been at Square for a while now, and you’ve seen it scale widely. What sort of organizational changes have you seen as Square has grown?
SQ: Scaling a startup from small to big is really interesting. It’s definitely stressful. If you’re doubling in size over a year, or even more frequently than that, one of the interesting challenges is that any decision you make today, if you wait a couple months, less than half the people in the company are going to know about that decision. So you have to be very explicit about what you’re doing and why. Especially with regard to inherent culture and build-versus-buy decisions, we can decide them now, but we have to keep repeating them in order to actually make it stick.
WH: What keeps you up at night in the industry? What’s the biggest problem facing financial services as a whole?
SQ: One of the largest problems facing the industry today is passwords—how many passwords can you really remember? And if you use a password on one website and that website gets breached, then all of your accounts on all the other websites are also at risk. It’s a very human problem. How do you protect individual humans without making them memorize 16-digit crazy things for every website they visit?
I think that there’s a UX or human interface component that we have not solved in this industry. We really need to.
WH: Sometimes usability and security can be opposing forces. Square seems to have done a very good job making the experience very elegant and also secure. How do you make those tradeoffs?
SQ: Anytime you’re asking an end user to make a security decision, something’s gone wrong. Individuals have a very hard time making calculated tradeoffs, partly because decision points are complicated and there are lots of variables to weigh. Not everyone can be an expert. So at Square we certainly tried to make sure that the product just works—that when you plug in the Square reader it’s safe, it’s secure, it’s encrypted.
In general, that’s probably the right way for other products to approach the problem as well. Because if you’re intruding on the customer experience by making customers decide to allow an action, everyone’s going to say yes, and you’re not really making anything more secure.
WH: A lot of the benefit of Square is that security happens automatically in the backend. But when you’re a small startup you don’t have those same resources. What suggestions would you have for small builders as they start to weigh these usability-versus-security decisions?
SQ: The space has gotten a lot better over the past decade or so, especially with the rise of certain platforms and frameworks. Similarly, various offerings from companies like Amazon and Google have protections already built in, so the task of achieving security has become much easier for small companies who can just buy things off the shelf.
When it comes to authentication, I would encourage companies to use something like Facebook Login or Google Login, which are great ways to outsource the problem. As the ecosystem gets richer and has more startups, and companies are building on these platforms, more of these services will be available. That’s going to make it easier.
In general, though, if you know you are making a tradeoff around something that’s sensitive and important, you should look for folks out there who can help you make those decisions.
WH: There’s a debate about who should be held responsible for the risk of credit card fraud, whether it be Square, the consumer, or the issuer. Where do you think it should go?
SQ: I think individuals should not be liable for the bulk of credit card fraud, and, by law, that’s the way it is in the U.S. If you compare the U.S. to other markets around the world, it’s clear that we have much lower friction: It’s much easier to buy things online or to go to a store. That’s one reason why the American economy is so strong, because it’s so easy for people to buy the things they want to buy and do the things they want to do. If we were to shift the liability to consumers, we would create huge barriers to the economy, so that’s ultimately the wrong way to apportion liability.
The only way that makes sense to me is to figure out who has the most ability to prevent fraud, or to prevent risk, and apply liability there. So for some forms of fraud, the merchant is in the best position. If someone comes in with an obviously stolen identity and is trying to buy fifty TVs, the merchant should be able to detect that that’s a weird transaction and stop it.
But if I have an EMV chip that has all the right data, it’s impossible for a merchant to tell the difference between that and a compromised card of some sort. In those cases, the bank should write the bill.
WH: So when something goes wrong with a transaction using Square, how do you determine whether you are liable, the merchant, the network, or the bank?
SQ: The card networks make those determinations. Operation regulations from Visa and MasterCard determine liability in very precise ways.
Square’s real value-add is to make that process much simpler for our merchants. And because we mediate between our customers and the networks, we can build a product to maximize protections to make sure that, for example, invoices contain clauses from the terms of service that maximize the chances that our customers will win chargebacks and disputes.
WH: Credit cards have this pretty incredible sticking power. No matter how many people try to replace them, they stick around. Are you bullish on any other alternative forms of payment, like Apple Pay, Bitcoin, consumer ACH, or anything like that?
SQ: Good question. Certainly, as a company, Square will make sure to support every form of payment that our customers want to accept, so we are in some ways agnostic to this. In the past, we have made it possible to accept Bitcoin, for example, and we’ve discussed other alternative forms of payment. In the U.S., credit cards are certainly the dominant form, and I don’t see that being unseated anytime soon.
Will it be that way long term? I don’t know. I especially think that the card part of credit cards may be anachronistic in a few years. Maybe everyone will have card-centric wallets, but will also have things like Apple Pay, or want Apple Watches, or EMV cards embedded in wristbands. There are lots of ways to accomplish these transactions, and they don’t necessarily need to be cards. There will have to be some sort of centralized rails, though, that can handle these transactions.
WH: From a risk and security perspective, do you still focus most of your time on Square’s POS product, or have you diversified and focused more on some of your newer product offerings like Cash, Capital, and Payroll?
SQ: We watch all of them closely. Our core payments-processing business has been around for a number of years now and achieved pretty large scale. There are a lot of things for us to focus on, but we’ve also got a lot of experience running those things.
Some of our newer products are moving very quickly and their customer bases are changing, so that makes it a much more interesting challenge on the risk and security side: on the one hand paying attention to the product iteration and making sure we’re managing our risk well, but on the other hand making sure we’re not getting in the way of the product team or causing undue friction internally or externally for our customer.
WH: How have you managed to embed yourself in all the different teams at Square to make sure that everybody is thinking security first?
SQ: We’ve taken a number of different approaches over the years. The most important thing is to establish a culture of security where engineers feel responsible for the security around the product and feel empowered to make decisions, but also feel the moral weight of making good decisions. Once you can establish that, we find that engineers come to us with questions. So if the engineers know that they need to make a decision about something they can come to the central security team for guidance, and we can then build libraries, tools, frameworks, or whatever else makes that question easier to answer next time.
Ultimately you want to make it so that the easy thing for an engineer to do is also the right thing. So it’s mostly about pushing decision making out and then centralizing the infrastructure that supports it.