Today, local warrant officers find fugitives of misdemeanor warrants in the same way they did in the 1970s: paperwork and legwork. Nick Selby’s company StreetCred seeks to change all that by synthesizing data from police, tax, court, and public records to prioritize fugitives, so that cops can focus on the fugitives who are easiest to find. By flagging so-called “frequent flyers,” who are repeat offenders, and those with a history of violence it also helps keep officers safe. FastCo.Labs spoke with him about how his time in uniform influenced the project–and why empathic abilities are crucial to building niche software products, especially for businesses and governments.
What’s the problem that StreetCred solves?
One of my first days out of the academy, I’m riding with Dave and we get to this apartment complex where we have a guy with a warrant. Dave looks at the complex and back at me and says, “Brother, he’s in the wind.” I said: “Did you look at his warrant? How do you know?” So we go over and check, and the landlord says the guy moved out three months ago. Dave didn’t have to even look at the warrant. He just knew that, at that time, it took about 300 days for our agency to process warrants. He knew that if you are the kind of person who doesn’t pay a speeding ticket, you are the kind of person who doesn’t pay your rent, and since he’s a local cop he knew that this apartment complex deals with lots of transients. This is exactly the kind of hunch we want to capture. The average fugitive is worth around $900, of which my city gets to keep 47% on average. If I arrest him, I don’t get that $900 and it costs me $700 to keep him in jail for three or four days before the judge throws him out for time served. The objective is not to arrest people but get them to pay you. A rich person you can’t find is as bad as a bum you can. Right now the city of Houston, Texas has a $300 million warrant backlog. We believe that’s closer to $150 million of findable warrants.
How did you end up making software for cops?
I’m an information security guy–I established the security practice at analyst firm the 451 Research Group–but I wanted to do some public service, to find a problem and solve it with technology. After looking for a year and a half I realized that local law enforcement technology was a basket case. They were 15-20 years behind. Then I met [StreetCred cofounder] Dave Henderson, who’s a city marshal and fugitive task force member, and he explained the misdemeanor warrant problem. I realized the only way that I could solve that problem was to go to the police academy to understand the problem better, which I did for five months at the age of 45. I was sworn in as an officer in 2010 and started working on every aspect of this from writing the tickets to getting the warrants from the court to going out and finding the fugitives. In early 2011, when our software was in pre-beta stage, I started taking it out to test it and we did a year-long beta test with another warrant officer.
Why haven’t law enforcement organizations embraced technology that could help them recover some of their warrant backlog?
Most technology for law enforcement was invented someplace else and adapted to law enforcement, by people who don’t work in law enforcement. Cops tend to be unsophisticated in terms of technology. It’s just not a requirement. When I went to the police academy, all my classmates were in their early 20s and none of them could work their computer. In law enforcement, lives really do depend on technology. So once something works, there’s a cultural aversion to changing it. The other cultural issue is that if a cop messes up, because everything he does is public record, you get suspended without pay. So cops don’t want to learn anything new since every new thing is seen as just another way I can get in trouble. They don’t like technology, they don’t like buying technology, and when they buy it they tend to let it sit there. The result is Reagan-era backends and Clinton-era frontends. Recently, I saw a college-educated woman whose job is to type data from one screen into another screen because the databases don’t talk. There is no technical reason why officers have to get killed every year because the information was in one database and should be in another.
This article branches off a larger story we’re tracking: Who’s Afraid Of Data Science? What Your Company Should Know About Data
What kinds of data do you look at?
We’re using Big Data techniques, but the data we use, while important, heterogeneous, and disparate, is certainly not “big.” We use a four-point scale to grade information. The only way an address is marked as a good address is if an officer goes out there and marks it as good. An officer telling me that they spoke to a neighbor is worth more than an administrator or dispatcher speaking to a neighbor. All of this is worth more than if I found it on Facebook, which is worth somewhat less than if I found it in public records. I can tell from statistical analysis that when a particular officer writes tickets, 90% of the time he is getting all the information you are supposed to get. So when someone says they work at Taco Bueno he’ll say “Which Taco Bueno?” That three-second interaction saves 3-4 hours on the warrant side. A cop who works narcotics will only write a ticket to establish probable cause to pull someone over, so he’ll just write down “Taco Bueno” since he only cares if the guy is hauling meth. People lie all the time, but there are a couple of things they don’t lie about. They don’t lie about whether they are dead so we check the social security death index. That’s a very good indicator of someone’s ability to pay. If there’s a dog license database we want that–you will put the right address because you want your dog back.
A couple of companies have an API. Some give us read-only access as a user and we can run SQL against it. Several of them just give us text-file dumps, non-delimited in a completely proprietary format. We don’t charge to give you back synthesized, normalized data. Many of the contracts for law enforcement IT say that the vendors own the data even when it is public record or the agency’s own data. We share the data in order to foster competition, to make the technology better and ultimately make it into some kind of platform.
What data analysis techniques do you use?
What we seek to do is disqualify bad warrants. We ask questions to knock people out of consideration. We ask a fairly straightforward set of questions, almost 130 sets, in which we set flags, and the flags mean they are less likely to be good warrants. It’s aggregation, correlation, and prioritization of data to make more effective use of public money to find people who are wanted by the law. Most of the warrants are backlogged and older than 36 months. You are never going to find those people. In some big cities they have warrants going back to the 1950s that they can’t get rid of. We can go through your entire warrant corpus and say: “Show me all the warrants which are more than 36 months old, where the target hasn’t had a drivers license for a year and public records indicate that we can’t find them.” Put that into a pile and send it to the district attorney for dismissal since it costs more to maintain them than we will even get out of it. Our ability to objectively score warrants for dismissal is something that’s never been done before. If you get an officer whose ratio of collected to cleared warrants (fugitives found versus fugitives who paid) is less than average, that officer is going after the wrong people. For the first time ever an administrator can set thresholds and guidelines and say, “Of the last 10 people you arrested, four could not pay.” Maybe you need some more training?” Now for the first time we have performance metrics.
Can you apply the same techniques to criminal warrants?
We are now looking at using most of the same questions, all of the same data sets, most of the algorithms and heuristics, but taking out the information about ability to pay and just looking for bad people who need to be in jail. That turns out to be very similar. The other application which neither of us had thought of, because we hadn’t worked there, is gangs. Gangs in the United States are tremendously under-reported. There are active gangs in every major city. The numbers would terrify you. Often agencies are only trying to keep track of these guys and like warrants, all of this is on paper. What they are trying to do is show a police presence. You have a gang war and just like in Starsky and Hutch, they bring them all in for a sit-down and when that failed the strategy is to get all of our field officers to talk to these guys as often as possible and show them that you are watching them, easier said than done if you can’t find them.
Any advice on developing data-based products for non-specialists?
Look for a genuine problem to be solved, not a way to leverage some technology. Really understand the problem that you seek to solve. For example, we have one of the ugliest UIs in the world, and unless you are a cop it’s very difficult to understand why. On the left hand side is what we call the pedigree: the person’s image and an image of their car model. This is designed to be used on a portable computer in a moving unmarked car, and all we want to give you is the ability to see that person on the street or the car in the driveway. Some of this information looks redundant but it isn’t, e.g., age and date of birth. The age is so I know how old the person who I am going to encounter is. The date of birth is to confirm her identity once I see her. The area on the right changes. It shows home address and home street view when you are still driving. We require almost no keystrokes. Cops hate typing, and they are in a car so they are not allowed to type while they drive. Everything is one click away except when you are parked. We are anticipating the workflow in the order in which we believe a cop will do it but we don’t require them to follow our workflow order.
[Photo by Flickr user Eric Fischer]