 Hi, and welcome to pioneering open source at the CFPB. My name's Adam Scott. I'm the web development lead at the CFPB. I'll be joined by my colleagues, Eric Spry, who's our HUMDA operations lead, Jennifer Lasser, who's our program operations lead, and Tim Lambert, who's a senior counsel in the Office of Fair Lending and Equal Opportunity. The CFPB is a government agency formed after the 2008 financial crisis, and we were tasked with regulating and providing education for consumer financial products in the United States. Looking at a new government agency, that's not something that happens very often. So we really had an opportunity to set forward a vision and motivation for technology that's modern and innovative. And a big part of that was thinking about how we would integrate open source into the Bureau's mission. And so we set forth in those early days with some vision and motivation for that to use and create open source software that would help us accomplish our mission effectively and efficiently. We also thought that since the Bureau uses government resources to create source code, we should provide access to the public to that creation. We also believe that open source code provides a public window into how a government agency fulfills its mission to the public and that sharing code could make our products better by allowing us to receive and incorporate feedback from the public. So we set forth with that the Bureau opened stores in 2011 and less than a year later in April of 2012 released a source code policy along with our first two open source code repositories. Six days after releasing those two open source code repositories, we received our first pull request from a member of the public. It was a simple typo fix, which is a frequent first pull request. But it was the first time that a government agency had accepted a pull request from a member of the public. So it felt really groundbreaking and exciting that we were onto something. And so in those early days, we took this initial approach to open source where we would develop source code in a closed environment. And then we'd thoroughly vet that source code and then potentially release it publicly. So that's what we saw with those first two repositories. But in the spring of 2013, our team had grown and we really saw an opportunity to start developing in the open. So to provide that transparency and that vision from the start of our projects so that we can encourage that public collaboration, communication throughout the development process. And you can see here, this is our first project that was developed in the open. And in parallel with that, we also started to move our existing source code to the open. So we formed an open source working group. That working group defined a checklist for migrating internal source code to our public GitHub. And you can see here I've linked to that checklist. We've made that available. And we worked to move our repositories to GitHub.com one by one. We worked with the maintainers of those repositories or that open source working group. And that brings us to our approach today where we really work in a way that's open source by default. So rather than develop and close and make exceptions where we develop in the open, we really aim to develop in the open from the start as much as possible. The lifecycle for that code looks like this. We develop our code. A developer makes a pull request to integrate that code into our code base. And when that happens, we run a lot of automated checks, both publicly on GitHub but also internally that check things for security and code quality through linting and tests. We also require a manual review. So we do the automated checks but also a full-time developer on our team does a review of the code. And then finally, we deploy and release that code. And this cycle can happen several times a day. So this is something that's an ongoing process on our team. Now, even though we aim to release things as open source by default, there are exceptions. Sometimes the code is just too crude. It's intended to be a prototype or something that we're doing testing on. Other times we may not have the open source rights to do something. A license doesn't permit us to release it as open source. So other times there may be some law regulatory requirements that forbid it or there's security risks by releasing something as open source. But these really are the exceptions to the rule. By and large, the vast majority of our work is able to be released in the open. And today we really have taken a varied approach to open source. So we've really looked at making this a core part of the way we do development and release information through technology. So we have 299 open source code projects on our public GitHub at this time. And that includes large projects like our public website or the HUMDA filing platform, which my colleague Eric will speak about shortly. We also have things like cross government initiatives such as interactive regulations, which we've created and have been forked and used by other government agencies. We also look to build general purpose projects where we're building something for our own use and we think that could be extracted and used by the larger open source community. One example is our flag library, Jango Flags. And we also look to use open source outside of traditional code models. So one example is our models for disclosure notices, which are regulatory requirement. And they help businesses more easily comply with our rules. So we release those notices on GitHub and they're available for the industry to take and use and build upon. And then we invest in open source. So members of the CFA development team participate and are encouraged to contribute to open source products that we use. For example, Wagtail, which is the content management system that our website uses. Two members are our development team. We're on the core platform team for Wagtail. And many members of our development team have contributed back to the Wagtail ecosystem. With that, I'll pass it to my colleague Eric Spry, who can talk a little bit about the HUMDA platform and how we've leveraged open source in that platform. Thank you, Adam. It's really fascinating to introduce our open source policies. And then now I'd like to talk about how we've applied those policies to a program. The HUMDA operations program, HUMDA for short, is the Home Mortgage Disclosure Act, which requires certain lenders to disclose who they are lending to and under what terms. The HUMDA platform is a regulatory reporting system that collects stores and publishes this information. I'm excited to share a bit about how we developed this platform in the open and why it matters to the open source community. So platform development process. The HUMDA platform was developed in-house at the CFPB with an eye towards the future of regulation technology. By studying pain points that the lending industry had with an older process, we developed a web-based application based on insight from filers. The ideas that came out of our early studies resulted in a pilot application in 2015, a kind of first draft of the HUMDA filing application. The platform had an ambitious goal to use the bleeding-edge technology of 2015 that we hoped would be state-of-the-art by the time we went into production in January of 2018. That strategy worked out and I'll talk a little bit more about that later. Ultimately, the work of my team has been informed by the engagements we've had with our public stakeholders and with industry. Open source development. One of the principles we follow is transparency in a code we write, as Adam outlined. This is part of our showing our work and hopefully sharing back to our stakeholders. The open source code can be used by interested parties to recreate the entire HUMDA platform locally, test our code and offer opportunities to suggest improvements. I'm very proud to say that a number of contributions from outside CFPB have become part of the HUMDA platform. For example, in the first production rollout of the platform, someone in the lending industry took a look at our code and realized they could make a suggested change to add a new helpful validation endpoint. That showed up as a GitHub pull request. My developers reviewed the suggestions, made a few tweaks and incorporated it into our platform. Another example, we had a bug in checking for a certain loan status flag. Our code had reversed a logical operator for a min-max values deep in the code base causing a problem for a few of our customers. One of our industry stakeholders had been digging through the documentation and found the inconsistency in the program code and submitted a GitHub issue. This is a very cool catch because the fix was quick and rapidly deployed as an update to the production system. What I often tell folks when I meet with the financial or compliance industry is bring your technical people so we can talk about APIs and code. API driven architecture. APIs are important to a lot of the lending industry in their compliance software and to people who study the lending industry. We have great documentation on how to use our APIs and how to integrate HUMDA resources into compliance checking process. Much of that documentation has been improved based on industry feedback via GitHub issues, pull requests and help desk tickets. The HUMDA filing API allows you to work with every stage of the HUMDA filing process, same as the web application. The public API is a good one for compliance checks because you don't have to use a specific user ID or log in so it doesn't require a token. The HUMDA data browser APIs, our data publisher allows you to use filtered and aggregated data along with CSV exports that can allow you to build an entire data analysis pipeline without the burden of ETL of the tens of millions of HUMDA records. Other tools also live in the same platform ecosystem and provide robust APIs for the industry to use in their systems. Technology forward. I spoke earlier about starting years back with bleeding edge technology so we could be closer to the state of the art in production. Some of those important technical elements have been container based microservices. This allows us to scale the platform in the right way and update specific services without causing downtime in others. As a team dedicated to the HUMDA platform, my team focuses on continuous improvement and optimization and tweaks code to make it better all the time. One of the ideas that we started with the whole program at the beginning was to connect the regulation with our code where possible. The domain specific language we developed for HUMDA is one such step. There's a lot of innovation happening across industry now that takes this idea even further. Stakeholder engagement. Lastly, I'll share that user testing, engaging with public and industry stakeholders and making improvements based on feedback are core to the way we like to work. A few examples. We heard from compliance vendors that they wanted a way to test their HUMDA systems, so we created a beta platform for them that's open year round for their testing and continuous compliance checks. Our help desk noted that users were finding certain error messages confusing, so we improved error messages to be more descriptive and clear. We've improved our user guides based on user feedback. We also heard from a large mortgage wholesaler that a full file validator would be very valuable to them, so we wrote one and published it. And lastly, we heard from all of our customers how the first production filing season went and asked them for a ways to improve our system. Based on that feedback, we wrote a lot of our code and improve the performance of the system. We accept feedback and suggestions for the HUMDA platform through industry contacts via HUMDA help at CFPB.gov or for your technically minded folks through GitHub poll requests and issues. We learn a lot by engaging with our customers and incorporate their suggestions and updates to improve the HUMDA platform. By sharing our code and connecting to our stakeholders, we have been able to make the HUMDA technology better together. Jen. Thank you, Eric. Continuing on the path of open source and innovation at the Bureau, I'm delighted to share details on the CFPB's newly christened text sprint program. As many of you are aware, financial regulators have a unique convening power to shape the direction of innovation, both in technology and where wider issues persist in the market. Following in the footsteps of the UK's Financial Conduct Authority success, the Bureau has adopted the text sprint as a key element in our innovation toolkit. In brief summary, as I'm sure many of you are already aware, but in this context, text prints are referred to as a typically two to five day event that bring together a wide range of subject matter experts from across and outside of financial services to develop technology based ideas or proof of concepts that address specific industry or policy challenges. As many of you also are already aware, the text print can take on several forms, traditional hackathon style preformed team hackathons and independent work competitions to name a few. In all cases, the participants are expected to show actionable ideas to an evaluation panel that have innovated on the presented challenge. During a data driven agency, it was only right that the first step to kicking off the text print program was a public request for information in fall of 2019. This request was valuable in many ways, but especially helpful engaging interest from the public and collaborating with the Bureau in this manner and identifying relevant topics for the Bureau's first sprints. By June 2020, the Bureau announced the first set of sprints and release their corresponding problem statements and set out to execute the inaugural sprint on October 5th through 9th. Summer was operations heavy with planning and recruitment efforts. We had several adjustments to the sprint as you can imagine that mirrored the world shifting to a fully remote status. Inside those planning efforts, the Bureau pulled heavily from the previously mentioned work of the Financial Conduct Authority, as well as a meticulously written text print manual released by the Alliance for Innovative Regulation, otherwise known as AIR. This manual was a companion how to to the FCA's efforts and in true open source spirit, those documents are available for anyone's use on airs website. On October 5th through 9th, we did execute our first sprint virtual I should note, including 13 teams comprised of various representatives from industry community groups, academics and technologists and globally located. The interest in terms of volume of applicants was well beyond what we had anticipated. I have several hypotheses for why that happened, but one of the stronger strongest drivers in my opinion was the recruitment effort made on behalf of the Bureau's markets and innovations teams. They were diligent in making phone calls for pre registration to validate both the problem statement and the value in companies collaborating with the Bureau in this way. We had most applicants come as pre formed team, a sign of the remote collaboration I believe, though we allowed for about 15 individuals to form their own teams the week prior to the sprint so I think traditional hackathon style team formation. And some of those folks also joined existing teams. Again, I believe the summertime calls helps at the stage for the expectations that teams should be multi discipline. And as a result, we saw most pre formed teams comprised of multiple companies and various subject matter expertise. It was truly impressive. During the week, the team sprinted independently with a 30 minute touch point back to the Bureau. This was an adjustment made to accommodate the virtual setting. We anticipated most participants would still be working across the week, different than in person execution of course, and that seemed to be accurate. In terms of preparation for the week we did a one hour kickoff the week prior to the sprint and allowed for team formation and problem statement conversations to occur via slack across that week as well. We also provided a text sprint toolkit with additional reading resources such as mock adverse action notices and recommended not endorsed a particularly relevant open source data set and model while also encouraging teams to use proprietary or other open source data sets and models. Friday was a traditional demonstration day and we convened an evaluation panel that asked questions and scored the demonstrations based on three categories, creativity, effectiveness and market readiness. The day included opening remarks from CFPB director Craninger and a keynote speech from Nick cook director of innovation at the FCA. We're in the midst of post sprint work, the hardest and most rewarding steps in the process in my opinion. These follow up steps include one on one deep dive meetings between Bureau staff and participating teams. Internal Bureau discussions around the innovations and their potential relationship to future bull making efforts, potential applications for the Bureau's trial disclosure program, and in some instances, innovations are already gearing up to go to market. We hope to have tangible progress through in all of these areas to report back on in the following months. The Bureau has several sprints in the queue for 2021. Our first as you can see will be held 20 March 22 through 26 and focused on the HUMDA platform you heard my colleague Eric's prize speak to earlier. I encourage everyone that is interested to go to consumer finance dot gov fill out a request for information for this sprint will be starting outreach within the next six to eight weeks and welcome everyone that wants to be involved into that process. So my turn back to you. So hopefully you've got a sense of the value and benefits we've experienced through our open source programs both the general practice, as well as how it's applied to our HUMDA program as one specific example, and also how we're taking that to and building on it with our text prints. So those initial benefits that we explored we've seen them play out we've seen that this provides an opportunity for our industry stakeholders to adopt shared code and build directly to our regulatory specific specifications. It's allowed the public and industry to review our source code suggest changes and make improvements. It's also been a signal to advanced financial technologists that we understand modern technology and development and are able and willing to collaborate. We've supported advocates academia students researchers by offering our free open access to our software and design work. And finally, it's enabled this cross agency collaboration, and really given us a jumpstart on on our work so we've been able to share our work with other government agencies and build on the work of our partners in government. This is just one step on our journey you can see we've come a long way in the past several years but there's a long way to go so I encourage you to reach out. If you're a part of this open source journey within your organization you'd love to talk and hear more about your experience and share around. Thank you. Thank you.