Before Regloom existed, I spent several years on the compliance team at a growing payment fintech. The company was processing transactions in a handful of states, licensed as a money transmitter, and subject to both state money transmitter regulations and federal obligations around prepaid accounts, Regulation E, and BSA/AML. The regulatory surface area was not enormous by bank standards, but it was large enough that no one person could track all of it.
What we had was a shared spreadsheet. It listed the regulations we were subject to, the controls that were supposed to satisfy each one, and a column for "recent changes" that the person monitoring each agency was supposed to update when something changed. We also had three email subscriptions: the CFPB bulletin list, a law firm's financial services regulatory update email, and a state regulatory newsletter for one of our larger licensed states. And every Friday morning, I spent about 90 minutes reading the week's publications from the agencies we tracked.
This system worked adequately when nothing was moving fast. It failed in three specific ways that eventually motivated building something different.
The Three Failure Modes
The first failure mode was coverage gaps. The Friday reading block covered the agencies I had personally prioritized. FinCEN, CFPB, and the state licensing authority for our largest market. But regulatory change does not respect your prioritization. The OCC issued interagency guidance one spring that was directly relevant to our bank partner arrangement, and it came from an agency I was not monitoring weekly. I found out about it six weeks later when a consultant mentioned it in a different context. By then, our bank partner had already received an inquiry from their examiner that referenced the guidance, and we had to reconstruct our documentation retroactively.
The second failure mode was the translation gap between "something changed" and "which control needs to be updated." When I did catch a regulatory change through the Friday reading, the next question was always: does this require a control update, and if so, which one? The spreadsheet had controls mapped to regulations in general terms, but the mapping was at a regulation level, not an obligation level. A 40-page CFPB rule change that updated three specific requirements within a larger regulatory framework required manually reading through the rule to find the specific obligation changes, then manually determining which controls were affected. That process took hours for a complex rule change and was entirely dependent on me having enough background knowledge to identify the relevant obligations correctly.
The third failure mode was audit trail. When our bank partner's compliance team asked us for documentation showing when we became aware of a specific regulatory change and what action we took, the answer lived in my email history and in whatever I had written in the "recent changes" column of the spreadsheet. There was no systematic record of what we had reviewed, when we had reviewed it, and what determination we had made about whether it required a control update. In an examination context, "I checked and decided it did not require a change" is a defensible position if there is documentation. Without documentation, it looks like you never checked at all.
What We Looked For and Why Nothing Fit
Before building Regloom, we spent several months evaluating existing options. The market at the time had two categories of tools. The first was large GRC (governance, risk, and compliance) platforms designed for enterprise compliance programs at banks and insurance companies. These had regulatory monitoring features, but the products were built around workflow and risk management frameworks designed for teams of 20 or 50 people. The onboarding process for one platform involved a three-month implementation project. The pricing assumed a budget that a growing fintech compliance team does not have.
The second category was monitoring alert services, typically offered by law firms or legal research platforms. These would send a daily or weekly email digest of regulatory developments. They were better than nothing for coverage. But they were newsletters, not tools. They did not connect what changed to what it meant for your specific controls, and they did not produce any kind of audit trail that could be used in an examination.
What we wanted was something in between. Monitor the relevant agencies automatically. When something changes, tell me what obligation changed, not just that an agency published something. Connect that change to my specific control library. And keep a record that I can produce to an examiner showing what I reviewed and when.
That combination did not exist as a product for teams of our size and budget. So we built it.
The Core Design Decision: Control Mapping as the Output
The decision that distinguishes Regloom from a monitoring or alert service is that the output is a mapping to controls, not just a notification that something changed. This required solving a harder problem than coverage. Coverage is tractable. You identify the agencies, build ingestion pipelines, normalize the publication formats. It is engineering work, not conceptually difficult.
The mapping problem is harder because it requires the system to understand regulatory obligation text at a level of specificity that lets it associate the right obligations with the right controls. A transaction monitoring control and a suspicious activity reporting control both sit within BSA/AML, but they satisfy different regulatory obligations and are affected by different types of rule changes. A system that maps "BSA/AML rule change" to "all BSA/AML controls" is not much better than the Friday reading block for reducing triage time.
We spent the better part of the first year getting the obligation extraction and mapping logic to a point where it produced results that a compliance officer could trust as a starting point rather than treating every mapping as needing manual verification. The confidence scoring we added in Feed v2 was a direct result of learning that users needed to know when to trust the system's mapping and when to look more carefully.
What We Are Still Learning
Regloom is not a finished product. The coverage gaps we have today are in state-level monitoring and in certain categories of regulatory publications that are less consistently structured than formal rulemaking. The obligation extraction still struggles with guidance documents that use narrative formats rather than numbered regulatory text. We know about these gaps because users tell us when a change they care about was not surfaced or was surfaced with incorrect obligation attribution.
We are also still learning what the right user experience is for the compliance officer who is not a dedicated regulatory tracking specialist but who needs to stay current without spending 90 minutes every Friday morning doing it manually. The product design question is about how to make the review process fast for the items that are genuinely low-priority and ensure that the items requiring real attention are immediately visible. That balance is harder than it sounds when regulatory publications vary enormously in their significance and their complexity.
The reason we are public about what is not working is that the problem we set out to solve is real. Compliance teams at growing fintechs and community banks are doing regulatory monitoring manually, with inadequate tools, and carrying the risk that comes with gaps in coverage, gaps in documentation, and gaps in the translation from "what changed" to "what do I need to update." We built Regloom because we were that team. We are still building it, and the problems still need to be solved better than they are today.