What an AI operating system for collections must enforce

Before deciding what an AI system should do inside a collection agency, it is worth looking at what consumers actually complain about, because it is not the thing most agencies automate first. The Consumer Financial Protection Bureau reports that it "received approximately 207,800 debt collection complaints in 2024—seven percent of total complaints received that year", and that of those, "the most common issue was attempts to collect debt not owed". Inside that category the breakdown is the useful part: most consumers who said the debt was not owed reported that it was "not their debt" (60 percent), that it resulted from identity theft (28 percent), that the debt was paid (10 percent), or that it was discharged in bankruptcy (three percent) (Consumer Financial Protection Bureau, Fair Debt Collection Practices Act CFPB Annual Report 2025, November 2025, covering 2024). Almost none of that is a conversation problem. It is a data problem — wrong party, wrong status, wrong balance — so the highest-leverage automation in a collections shop sits upstream of anything that talks.

The second thing that makes this domain unusual is that a large share of its rules are written as arithmetic. Most regulated workflows come with standards a system cannot check for itself; a meaningful part of federal debt collection law comes with counters, clocks and flags, which is what makes an operating system possible here rather than merely a chatbot. What follows is the set of rules that changes your data model, from the current text of Regulation F, with the matching findings from the CFPB's examinations of larger debt collectors — because those show which rules people get wrong when the rule lives in a training deck instead of in software.

Start with the one everybody can recite and few implement correctly. Under Regulation F, a debt collector "is presumed to comply" with the prohibition on repeated calls if it places calls to a particular person about a particular debt neither "More than seven times within seven consecutive days" nor "Within a period of seven consecutive days after having had a telephone conversation with the person in connection with the collection of such debt", and the rule adds that "The date of the telephone conversation is the first day of the seven-consecutive-day period" (Consumer Financial Protection Bureau, Regulation F, 12 CFR § 1006.14). Two clauses in that sentence decide your schema. The counter is per debt, not per consumer — the regulation defines "particular debt" as "each of a consumer's debts in collection", with a carve-out that treats student loan debts serviced under a single account number as one. And the freeze is triggered by a conversation, not by a payment or a promise, so your telephony layer has to be able to say what counted as a conversation and when.

The exclusions matter as much as the limits, and they are where systems built from a summary go wrong in both directions. Calls do not count toward the frequency limits if they are "Placed with such person's prior consent given directly to the debt collector and within a period no longer than seven consecutive days after receiving the prior consent", if they are "Not connected to the dialed number", or if they go to certain third parties. Increment the counter on dial attempts and you suppress contact you were entitled to make; increment it only on connects and you exceed the limit. A system that stores only "attempts" has already lost the information needed to answer either question.

Quiet hours look simpler and are not. The rule prohibits communicating "At any unusual time, or at a time that the debt collector knows or should know is inconvenient to the consumer", and then supplies a default rather than a definition: "In the absence of the debt collector's knowledge of circumstances to the contrary, a time before 8:00 a.m. and after 9:00 p.m. local time at the consumer's location is inconvenient" (12 CFR § 1006.6). The statute says it from the other direction: a collector "shall assume that the convenient time for communicating with a consumer is after 8 o’clock antemeridian and before 9 o’clock postmeridian, local time at the consumer’s location" (US Government Publishing Office, 15 U.S.C. § 1692c, United States Code, 2023 Edition). Two engineering consequences follow. The window is anchored to the consumer's location, an inference from data you may hold badly — a mobile area code is not a time zone — so the system has to know how confident it is about the zone and behave conservatively when it is not. And the clock is only the default; actual knowledge overrides it. The CFPB's examiners found collectors sending "payment reminder emails to the consumer before 8 a.m. in the consumer's time zone", and separately found "multiple instances where consumers told debt collectors' agents that it was an inconvenient time to talk, either because they were at work or driving, but the agents continued the conversation". An inconvenience stated out loud on a call is a durable fact about that consumer, and if your system cannot capture it from the conversation and honour it on every channel afterwards, the clock is not enough.

The most important architectural lesson in the CFPB's 2025 report is that a presumption of compliance is not a permission. Examiners described collectors who kept calling after consumers asked them to stop: "Despite this request, the debt collectors subsequently placed over 100 telephone calls to the consumers." The rest is worth quoting in full — "Although the frequency of calls to the consumer was within the limits established by Section 1006.14(b)(2)(i), and so the collectors were entitled to a presumption that their conduct was not harassing, examiners found that the collectors placing over 100 calls to the consumer after being specifically asked to stop overcame that presumption and had the effect of harassing the consumer." A system whose entire compliance story is a seven-in-seven counter would have authorised every one of those calls. The counter is necessary and insufficient. What is also needed is a state the consumer can set, which outranks the counter and which no amount of arithmetic clears.

That state is written into the rule as well, and it is more granular than most systems model it. A debt collector "must not communicate or attempt to communicate with a person through a medium of communication if the person has requested that the debt collector not use that medium", with narrow exceptions: an electronic confirmation "containing no information other than a statement confirming the person's request and that the debt collector will honor it", and a single reply in the same medium if the consumer initiates contact through it. Examiners found collectors communicating "through a medium of communication, such as a text message, and/or through a specific telephone number that the consumers had requested the debt collectors not use". So the suppression record is not a boolean on the account. It keys on the person, the medium, and often the specific address or number, and it has to survive the consumer being re-placed, merged, or appearing on a second file.

Notices are the other half, and they are where the obligation extends past your own systems. Validation information must reach the consumer either in the initial communication or "Within five days of that initial communication", and anything sent in writing or electronically must go "in a manner that is reasonably expected to provide actual notice, and in a form that the consumer may keep and access later" (12 CFR § 1006.34 and § 1006.42). Actual notice is a delivery outcome, not a send event: examiners found collectors who had not met the requirement because the initial communication happened by telephone "after the debt collector had received notice that its prior written disclosure was not delivered to the consumer". Bounces are compliance data, not deliverability noise. Examiners also found that collectors' own service providers "failed to disclose that the communication was from a debt collector" — every vendor in the contact path inherits the obligation, and the audit trail has to span them.

Furnishing has a precondition that belongs in code rather than in a runbook. A debt collector "must not furnish to a consumer reporting agency ... information about a debt" before it either "Speaks to the consumer about the debt in person or by telephone" or "Places a letter in the mail or sends an electronic message to the consumer about the debt and waits a reasonable period of time to receive a notice of undeliverability", during which it "must permit receipt of, and monitor for, notifications of undeliverability" (12 CFR § 1006.30). That makes furnishing conditional on an evidenced communication event rather than a days-since-placement timer, and the system has to hold the evidence, because the question will eventually be asked about a specific account on a specific date.

Put that together and the architecture writes itself — which is the argument for building a system rather than buying a conversational tool. Every rule above is deterministic: a counter, a clock, a suppression record, a delivery outcome, a precondition. None is a judgement call, and none belongs in a model's discretion. They belong in a control layer that every outreach request passes through before anything is sent, which returns permitted or not permitted with the rule that decided it, logged with the policy version attached. The model's job is the part that is genuinely linguistic — understanding what a consumer said, drafting inside approved templates, spotting a dispute or a hardship disclosure in a sentence that does not use either word, and escalating when it is unsure. That split is what AI agent development in a regulated workflow actually looks like, and it is why the compliance layer is cheaper to build than it sounds: it is mostly a permissions system, and a permissions system is a solved problem.

What this article deliberately does not claim is as important as what it does. Everything above is quoted from three sources anyone can open: the current text of Regulation F as the CFPB publishes it, the Fair Debt Collection Practices Act in the United States Code, and the CFPB's own annual report to Congress. Collections is also governed by the Telephone Consumer Protection Act, by state licensing and call-recording law, by the Fair Credit Reporting Act's furnishing rules, and by payment-card security standards — none of which were verified here, so none of them are described here, and no system should be built against a summary of them written by anybody, us included. The same goes for performance: published liquidation-lift figures for AI-led collections come from vendors selling AI-led collections, and the only number worth anything is the one measured on your own portfolio against your own comparable accounts.

The practical order of work follows the complaint data rather than the demo. Fix the inputs first — party, status, balance, bankruptcy, deceased, representation — because that is the category consumers complain about most. Then build the control layer, because it makes everything after it safe to automate. Then digital-first outreach, then self-service resolution, and only then anything that speaks. The failure modes that show up when this meets your platform of record are catalogued in what breaks when AI meets a system of record, the interface question for a system that will sometimes be wrong is in designing an interface for a system that is sometimes wrong, and the full build — placement intake through furnishing and QA — is described as an AI operating system for debt collection agencies. If something is already running and you want its failure modes named before an examiner names them, our free production-readiness diagnostic reads a description of what you built and returns them in order.