Programming

The District Software Stack: Modern, Fast and Secure

9/17/2019 by Eduardo Pinheiro

At District, we are automating commercial real estate (CRE) lending. That means we are bringing the whole process, from applying for a loan, submitting documents, getting pre-approved and vetted to performing due diligence, underwriting, closing and servicing online. We will also allow this end-to-end process to be completed with as little human intervention as possible -- yes, like a credit card application.

District was founded in late 2018 and although there is still a lot to build, we have made strong progress to date. Our initial focus is helping borrowers and brokers fund short-term commercial real estate loans (ranging in size from $2 million to $20 million). These loans often have terms that can range from 6 months to 3 years with extension options. Although many of our loans focus on multifamily properties, we can also fund loans on office, retail, industrial, and hotel properties.

District offers a fast and secure online flow for borrowers and brokers to apply for and get a CRE loan. This online application is a part of our District Real Estate Automated Mortgage System (DREAMS) portal, where brokers and borrowers will eventually be able to manage their entire loan process from start to finish. In addition to serving as an online application and pre-qualification engine, the DREAMS portal also allows borrowers/brokers to submit documents and review and sign loan term sheets. Eventually, the DREAMS portal will also handle loan processing, underwriting, closing and servicing.

All of this does not happen overnight, of course. But we are taking the necessary steps to get there as soon as possible with the aim of delighting our customers, investors, and partners. One might wonder, how do we get there as fast as possible while making it fast, accurate and secure?

Enter our technology stack.

We use modern tools and practices in our development process. Below, we will dive deep into our decision process and what our best practices are. To cut to the chase, we use Go as the programming language for our backend and Angular on the frontend. Backend refers to what runs on our servers in the cloud and is what powers our application programming interface (API), while frontend is the code that runs on your browser when you access District’s servers.

However, as we will explain below, there is much more to what we use behind the scenes than just using two programming languages and a framework. Security is a top priority in the financial space and at District we take that seriously.

Choosing a Backend Technology

Selecting the right technology to build our API requires taking a hard look at security and testing practices offered by the language, the framework and the libraries involved. To name the most logical choices in this area there are: PHP, Ruby/Rails, Python/Django, Java and Go. And yes, one can build an API in NodeJS, .NET or even F#.

For us, Go was the logical choice for a few reasons. For a customer-facing application, speed is very important. The mortgage industry requires a lot of number crunching and so using a fast, compiled language makes sense. The alternative would be to have two languages, one to do the web serving and one to do the number crunching, which adds complexity and requires that engineers be well-versed in both.

In terms of security, Go also has a smaller surface area in terms of potential for attack than many other languages. For example, Go has its own high-performance web server which means we do not need to put a standard web server in front of it, making it less likely that a configuration mismatch between these two systems could accidentally open a backdoor for attacks.

Moreover, languages like PHP, Ruby and Python are either weakly-typed (PHP) or dynamically-typed (Ruby and Python), which means that there is more room for runtime bugs when random inputs are entered into the API. Go is statically and strongly-typed, so a lot of the issues that arise from subtle nuances about how to handle data is minimized. If this all sounds Greek, here’s a good primer on the different type systems of programming languages.

Go is also easy to learn, because it was designed to be easy to learn. It is very testable, meaning, it has support for testing built into its standard tools and has strong community support for testing. Our engineers were also very familiar with Go, hence Go became a natural choice for us.

Choosing a Frontend Technology

On the frontend, we wanted something modern and fast that sets us up for success. Something that imposed some development order with the goal of avoiding spaghetti code. Just straight Javascript with libraries like jQuery is too easy to get out of control. Having some framework to impose order would be nice.

The two most prominent choices these days are Angular and React. Both are component-based, which means it is easier to structure, test and re-use code. Angular was born out of Google while React was a Facebook baby. Now both are actively maintained by a growing open-source community.

In the end, Angular won us over because it brings with it a new language called Typescript (originally created by Microsoft) that has the advantage of a type system that, as we discussed above, helps us structure code better and detect errors more easily. And it is still compatible with all browsers.

Development Process and Other tools

To ensure high quality and secure code, we have a development process that involves two key components: code reviews and automated testing.

Code reviews ensure that any and all code written is seen by at least one person on the team other than the author. This has three main purposes: 1) Helps catch bugs before they happen, 2) ensures accountability as no one single person can make changes unsupervised and 3) helps our developers uphold our coding style and best practices.

Automated testing means a lot of things, including black-box testing, regression testing and integration testing. We will focus on two important things here: 1) We require that any new functionality, however small it might be, is tested at least by code written specifically for testing that functionality. We also often have larger tests that cover multiple features; and 2) that these tests run automatically every time we do code reviews and before we launch changes to our live site. And it can be run as often as necessary while we are developing these new features.

Part of the code review and automated testing process includes using tools that look for specific vulnerabilities or other issues. For example, we run a vulnerability tool called Snyk, which scans all of our libraries for known vulnerabilities and fixes them or warns us so we can assess the risk and take appropriate counter-measures. With close to 500 dependencies, it would be a nightmare if we had to manually track versions and correlate them with known vulnerabilities.

We also run a style checker that helps developers and reviewers spot errors and issues with the code before they’re committed to our git repository (by the way, we use Github to store our code repository).

To ensure tests run during code review time, we employ a Continuous Integration (CI) tool. We used a few before we settled on SemaphoreCI. We also use it as a Continuous Deployment (CD) tool, to ensure our releases are always based on reviewed and checked-in code.

Also on the security front, just ensuring the libraries we use are not subject to known vulnerabilities does not mean they aren’t subject to unknown ones and that we didn’t accidentally leave doors open. So, we employ a few tools to help us “hack” our own site. Until recently, we used Detectify to generate a report of exposed vulnerabilities. We are now in the process of switching to Arachini and Metasploit and we are studying combining them with other solutions for more robust coverage.

These scanning tools contain a suite of security checkers, including fuzzers (throwing invalid random data into form inputs), SQL injection (trying to sneak database instructions into normal inputs) and other common attack vectors such as XSS, CSRF.

Our mantra is that not trying to hack our own application and site is a big security red flag. It is better to have our engineers break our stuff than discover others have done it.

Another important security aspect we are starting to invest in is automated log analysis. Logs are bits of information left around by our applications and systems that describe what is happening with them. Security experts can analyze these tidbits of information and detect things like intrusion and data theft. Unfortunately, analyzing logs automatically with accuracy (at least with few false positives) is very hard. But the bright side is that a lot of simple security checks can be done very easily and inexpensively. The more sophisticated attacks are harder to detect, but are also much less common because sophisticated attackers don’t try the entire kitchen sync of hacking techniques -- which are the clues in the logs that an attack is happening or might have happened. Many tools exist for this, and the first steps here are storing logs and performing simple queries.

Our servers are also “hardened”, meaning we don’t just buy them (well, we rent them from Google Cloud actually) and deploy our applications on them. We install firewalls, limit access to a very small set of system administrators, create read-only containers, ensure encryption is turned on everywhere, apply system software patches regularly and update all of the support software in the ecosystem around them.

Conclusion

The quest to automate commercial mortgage lending and delight customers has started. District is taking a fresh and serious new look at lending with a strong foundation that aims to be accurate, fast and secure. Our tech stack reflects a modern approach to this new look, with tools that bring the best technology to this old playing field. And we are only getting started.

District is a balance sheet lender re-engineering the commercial real estate mortgage process. By developing innovative technology, District is able to increase the speed and accuracy of deploying capital while increasing transparency into the lending process. As a national firm, we specialize in short- to mid-term bridge debt on all product types with competitive rates and leverage.

Follow Us

Freddie and Fannie

What to do with Fannie and Freddie?

In September, the Trump administration proposed a new plan to re-privatize Fannie Mae and Freddie Mac. Their proposed plan would reverse one of the first actions taken in order to address the great economic crisis of 2008. But any modification of the status-quo would certainly have enormous ramifications for lenders and borrowers alike. If everything is working so well, why not just leave things as they are?

Read the full story

10/21/2019 by Bill Lanting

KB 030718 Addicted To Making Life Hard Work Here s How To Make Life Easier e1520440559150

Improving the Borrower/Broker Experience with DREAMS

District is committed to improving the borrower/broker experience in commercial real estate lending through technology. Our DREAMS portal is simplifying the loan application submission while increasing transparency at every step of the lending process.

Read the full story

9/30/2019 by Drew Bowker

Building buildings

The Commercial Lending Process Should be Consistent From Day One

The commercial real estate lending world needs simplicity, transparency, and predictability - but above all, consistency. District’s goal is to improve the lending process supporting these tenets through the use of technology.

Read the full story

9/26/2019 by Spicer Matthews

Get Started

District is the modern commercial mortgage lender providing you with higher
leverage, low rates and fast closings. View our Loan Programs or get started here.