Open Sourcing DAP: Legal Outreach Software

I am open sourcing DAP under a non-commercial license. DAP stands for debtor advice program. DAP was a project at my old law firm to provide outreach to consumers being sued by debt collectors. DAP was written in Python, used an SQLite Database, interacted with an IBM mainframe and two web APIs to send information to consumers.

Note: This code has very limited application outside of a single city in the US and you won't be able to use it without special credentials, but there are segments of the code and problems we solved that others may find useful when searching. Also I wanted to show off what we did together. Kim Bradley and Carlos Ramirez assisted me with this project. Kim helped with match detection, logging, and debugging. Carlos helped with SQLite and API interactions.

Debt collection firms buy debt from credit card companies, hospitals, or retail outlets for pennies on the dollar and file hundreds of thousands of lawsuits against consumers to attempt to collect on them. These schemes are successful, even if only 1 in 25 consumers pay, thanks to automation and rapid scaling. See this Last Week Tonight segment on debt buyers. This segment is 100% accurate. Full disclosure: I previously worked on both sides of this phenomenon, as both a full-time creditor right's attorney and later as a public interest debtors attorney.

Consumers might not be aware of their legal rights when faced with a debt collection lawsuit, even relatively minor ones. Debt trolls rely on this. Being served by the sheriff can be scary. In my experience many consumers ignore these suits out of fear they could be jailed, which doesn't happen, but it is a very common belief. Also many consumers are so mired in debt, with no clear way out, they become depressed and ignore the lawsuits, hoping to deal with it later.

No single consumer or consumer rights lawyer has the resources to fight these debt trolls. I thought DAP might help even the playing field by providing information and a path forward for clients. The initial run was a series of solicitation letters with basic information about bankruptcy. The plan was to expand these to informational booklets. The letters we sent had to fully comply with the Georgia Rules of Professional Conduct for legal solicitation, as well as Federal regulations affecting bankruptcy firms.

We did hope a few recipients of these letters would go on to hire us as clients. This actually turned out to be a bad way to reach clients with creditor issues though. Turns out these clients do not open mail from law firms. But this approach may have applications worth exploring in family and criminal law.

What DAP does is scan a local county IBM mainframe, in this case a specific county in Georgia, for new cases filed since the last scan. It must do this across 4 separate courts and narrow down to civil cases. There are several quirks the application has to adapt for. For instance, foreclosures on vehicles left at the impound lot were styled LOT v. VIN which broke our name parsing algorithm.

The mainframe is accessed via a 3270 virtualized connection (py3270) and DAP interacts with the virtual mainframe terminal, scanning text by it's X:Y coordinate on the screen and sending text/[enter] through a virtual keyboard. In the initial step DAP scans the mainframe periodically based on last known case numbers, detects each new case, logs the data to a file, and then moves on.

On the next pass cases are filtered for known debt collectors, from a list stored in the database that can be easily updated. On the next pass the the debtor's information is cross-referenced against a known public database, in this case Pipl, to verify their contact information. On the next pass the debtors are mailed a custom letter sent from Lob regarding their legal rights from a template populated by DAP. Then, finally, the data is extensively logged for compliance purposes.

Because Pipl provides e-mail addresses, the plan was to send potential clients an e-mail via ClickSend. This is permissible under the CAN-SPAM Act and under the Georgia Rules of Professional Responsibility provided we offered an unsubscribe option and the e-mails complied with the provisions for written solicitations. We did never fully implemented this feature. We also planed a Facebook messaging outreach feature but were severely limited by Facebook's API.

DAP maintains an extensive logging system so that every almost every single interaction is recorded with as much data as possible for compliance auditing purposes. Every single decision was made with ensuring compliance with the Georgia Rules for Professional Conduct covering solicitation and other applicable Federal regulations.

DAP was intended to be modular and resilient, in that each step of processing can pick up where it last left off and if there is a failure in any step the other steps can continue. DAP also attempts to implement an object oriented programming approach on Python. Both of these were goals and we did not get all the way there but it was a valuable exercise in those areas.

In order to open source this, we used BFG to remove meta-data from the commit history.