Choosing FDCPA and CFPB-Compliant Debt Collection Software: What to Require and How to Vet a Vendor

Most compliance failures in collections do not start with a rogue agent. They start with a system that lets the agent do something the rules do not allow, then fail to keep a record of it.

If your platform places an eighth call in a seven-day window, sends a text before the consumer opted in, or cannot produce the validation history for a disputed account, the software is now part of your legal exposure, not a defense against it.

That exposure is not theoretical. The Consumer Financial Protection Bureau received roughly 207,800 debt collection complaints in 2024, about seven percent of every complaint it logged that year, according to the Bureau’s annual report on the Fair Debt Collection Practices Act.

A large share of those complaints involved debts consumers said they did not owe or communications they said crossed a line. Each one is a potential dispute, a potential examination finding, and, for a bank or a large agency, a potential headline.

The tooling you run collections on decides whether you can answer those complaints cleanly or whether you are reconstructing events from memory.

This guide is written for the person doing the buying: the compliance officer, the collections operations lead, or the risk manager who has to sign off on a platform. It lays out what the FDCPA and CFPB rules actually require of software, which capabilities to insist on, how to handle the data and security side, and how to audit a vendor before you trust it with a regulated workflow.

It is a requirements-and-questions frame, not a product tour. Software supports compliance. It does not create it. The rest of this piece is about telling the difference.

What the Rules Actually Require: FDCPA and Regulation F in Plain Terms

Before you evaluate a single feature, be precise about what you are complying with, because two different things get lumped together under the word “compliance.”

The Fair Debt Collection Practices Act (FDCPA) is a federal statute. Congress passed it in 1977, and it lives at 15 U.S.C. 1692.

It prohibits third-party debt collectors from using abusive, deceptive, or unfair practices when they collect consumer debts for personal, family, or household purposes. It is enforced by both the Federal Trade Commission and the CFPB, a point worth remembering because it means more than one agency can act. You can read the statute itself on the FTC’s site.

Regulation F is the rulebook that turns that statute into operational detail. It is the CFPB’s implementing regulation for the FDCPA, codified at 12 CFR Part 1006, and it became effective on November 30, 2021. Where the FDCPA says “do not harass,” Regulation F puts numbers and procedures around it. Three parts of the rule bear directly on how software has to behave:

• Call frequency. A collector is presumed to violate the rule if it calls a consumer about a particular debt more than seven times within seven days, or within seven days after having a phone conversation with that consumer about that debt. The full text is in 12 CFR Part 1006 on the eCFR. This is a per-debt count, and the exceptions are narrow.
• The validation notice. Regulation F specifies what a validation notice must contain: the collector’s name and mailing information, the creditor’s name, the account number if any, an itemization of the debt, the current amount owed, and clear information about the consumer’s dispute rights. Model Form B-1 in the rule gives collectors a safe harbor if they use it.
• Electronic communications and opt-out. The rule permits email and text messaging, but only under specific conditions around prior consent or a compliant opt-out procedure, and every electronic communication has to include a clear and simple way to opt out. There are also time-and-place limits: contact before 8:00 a.m. or after 9:00 p.m. in the consumer’s local time is presumed inconvenient.

If a platform cannot demonstrate that it enforces those three things by design, it is not a compliant collection system in any meaningful sense. It is a contact tool that leaves compliance to whoever is watching the screen.

FDCPA vs CFPB: Two Layers Your Software Has to Serve

Buyers often ask whether they need software that is “FDCPA compliant” or “CFPB compliant.” The honest answer is that these are two layers of the same obligation, and good software serves both.

The FDCPA is principle-based. It says a practice cannot be harassing, false, or unfair, and courts have spent decades interpreting what that means.

This is the layer where judgment lives: whether a particular message is deceptive, whether contact at a particular time was unreasonable, whether a communication reached a third party it should not have.

Software cannot fully automate judgment, but it can enforce the guardrails that keep judgment from being tested, such as suppressing contact with a consumer who is represented by an attorney or who has asked to stop.

Regulation F is rule-based. It turns principles into countable limits and required disclosures. This is the layer software is genuinely good at: counting calls, enforcing quiet hours by time zone, logging consent, and inserting the correct validation language.

When a vendor says its product is “Reg F ready,” what you want to confirm is that these mechanical rules are actually built into the workflow rather than left as settings an operator has to remember to switch on.

The design implication is simple. Ask a vendor to show you where the statute’s principles turn into hard system controls, and where the rule’s numbers turn into automatic enforcement. If a capability only exists as a policy document or a training slide, it is not in the software.

The 2026 Regulatory Picture: Weaker Federal Enforcement, Not Weaker Rules

There is a dangerous misreading going around in 2026, and any buyer needs to see through it.

The CFPB has had a turbulent stretch. Its funding has been challenged in court, its enforcement and supervision activities have slowed, and several legal challenges could reshape or shrink the agency. Some collection operators have taken that to mean the pressure is off.

It is not, for three reasons.

First, Regulation F is still in force. Nothing about the CFPB’s funding troubles repeals 12 CFR Part 1006. The call-frequency presumptions, the validation-notice requirements, and the retention obligations remain the law in 2026. A rule that is under-enforced is still a rule you can be sued under.

Second, enforcement did not disappear; it moved. The FDCPA is enforced by the FTC as well as the CFPB, and consumers themselves have a private right of action under the statute. States have also stepped in. California’s SB 1286, effective in July 2025, extended consumer-style protections to certain commercial debts of $500,000 or less, a signal that state regulators are widening their reach rather than narrowing it.

A federal slowdown often means state attorneys general and plaintiffs’ lawyers become the more active threat, and they tend to be less predictable than a scheduled examination.

Third, the records outlast the political cycle. Retention obligations run for years, and enforcement priorities can swing back. The safe assumption for a software decision, which you will live with for five or more years, is that the full rule will be enforced at some point during the platform’s life. Buy for the rule as written, not for the current enforcement mood.

Features to Require in the Platform

Here is the working requirements list. Treat each item as a question to put to the vendor, and insist on a demonstration rather than a data sheet. If the product cannot show it live, assume it does not exist.

• Call and contact frequency controls. The system should count contact attempts per debt, enforce the seven-in-seven presumption automatically, and reset the counter correctly after a conversation. Ask how it handles multiple debts for the same consumer, because the count is per debt.
• Quiet hours and time-zone enforcement. Outbound contact should be blocked outside 8:00 a.m. to 9:00 p.m. in the consumer’s local time, with the time zone derived from reliable data, not guessed.
• Consent and channel-preference management. Email and text consent, and any opt-out, must be captured, time-stamped, and honored across every channel and every user, immediately. A consumer who opts out of texts should not receive one from a different agent the next morning.
• Automated opt-out language. Every electronic message should carry a clear, simple opt-out method by default, not as an optional footer someone can delete.
• Validation notice automation. The platform should generate a validation notice with all Regulation F required content, ideally using the model-form safe harbor, and track the delivery date and the 30-day validation window.
• Represented the consumer and cease-contact suppression. When a consumer is represented by counsel, has requested no further contact, or falls under a bankruptcy or dispute hold, the system must suppress contact automatically across channels.
• Complete, immutable audit logging. Every communication, every consent change, every disclosure, and every user action should be logged in a record that cannot be quietly edited after the fact.
• Configurable rules without code. Regulations and state overlays change. You want a platform where a compliance administrator can adjust rules and thresholds without a development cycle, so you are not waiting on a vendor release to respond to a legal change.

None of these is exotic. The point of listing them is that “compliant” is a claim, and this is the list you use to test the claim.

The Validation and Dispute-Handling Workflow

One requirement deserves its own explanation because it is where a lot of platforms are thin: debt validation and dispute handling.

Debt validation is the process of giving the consumer, near the start of collection, the information Regulation F requires so they can recognize the debt and exercise their rights, including the right to dispute it.

Dispute handling is what happens after the consumer pushes back. Under the FDCPA, if a consumer disputes a debt in writing within the validation window, the collector must pause collection on that debt until it mails verification.

In software terms, that means the platform has to do several things in sequence without an agent having to remember any of them. It has to send a complete validation notice and record when. It has to recognize an incoming dispute, whether it arrives by mail, phone, portal, or email, and attach it to the right account. It has to automatically place a collection hold on the disputed debt.

It has to trigger the verification response and track that it went out. And it has to keep the whole chain in a retrievable record, because a disputed account is the most likely one to end up in front of a regulator or a court. Ask a vendor to walk you through a dispute from arrival to resolution on screen. The gaps show up fast.

Data Handling, Retention, and Security Controls

Compliance covers more than how you contact people. It also covers what you do with their data, and this is where banks in particular apply a second, stricter filter.

Start with retention, because it is a specific legal obligation, not a best practice. Regulation F requires a debt collector to retain records that show compliance or noncompliance with the FDCPA from the date it begins collection activity on a debt until three years after its last collection activity on that debt.

Call recordings, where made, must be kept for three years from the date of the call. Your software has to store the right records, keep them for the right period, and let you retrieve a specific account’s full history on demand.

A platform that purges data on a fixed schedule without regard to collection activity can put you out of compliance by deleting the wrong thing.

Then there are the security controls that protect that data:

• Encryption. Consumer and account data should be encrypted in transit and at rest as a baseline.
• Audit trails. The same immutable logging that proves communication compliance also proves who accessed what data and when, which matters for both privacy and dispute defense.
• Role-based access. Not every user should see every field. Access should be scoped to the role, and the scoping should be enforced by the system.
• Payment-data handling. If the platform touches card or bank-account data, it should meet the payment-card security standards for that data rather than handling it in the open.

For definitions, a data-retention and security-controls program is the combination of policies and technical measures, such as encryption, access restriction, retention schedules, and tamper-evident logging, that governs how long data is kept and who can touch it.

The independent proof most enterprise buyers now demand is SOC 2. A vendor compliance audit is only as good as the evidence behind it, and SOC 2 is an examination, performed by an independent CPA firm against the American Institute of CPAs’ Trust Services Criteria, of a service provider’s controls. Those criteria cover security, availability, processing integrity, confidentiality, and privacy, and you can read the AICPA’s Trust Services Criteria for the full definitions. A SOC 2 Type II report is stronger than a Type I because it tests whether the controls actually operated over a period of time, not just whether they existed on one day. Banks and larger financial institutions frequently go further, layering on their own third-party risk assessments and, for public-sector-adjacent work, FedRAMP-equivalent expectations. If a collections vendor cannot produce a current SOC 2 report, that is a finding on its own.

How Enterprise Platforms Push Compliance Into the Workflow Layer

At enterprise scale, the compliance logic cannot live in an agent’s memory or in a supervisor’s spot checks. It has to live in the workflow and decisioning layer, where the system, not the person, decides what is allowed for a given account at a given moment.

A large bank collecting across products, states, and sometimes countries cannot rely on training alone to keep thousands of interactions inside the rules.

The rules have to be encoded in the routing, the scripting, and the interface itself, and they have to adjust as an account’s status changes.

This is the market that enterprise FDCPA and CFPB-compliant debt collection software for banks and financial institutions is built to serve, and it is a genuinely different problem from single-agency collections.

One of the providers operating at that scale is C&R Software, whose Debt Manager platform uses a context-sensitive interface that adjusts to account status and regulatory requirements, pairs role-based access controls with PCI-DSS and PA-DSS certification, and is used across banking, fintech, and other regulated sectors.

That kind of tooling supports compliance by making the compliant path the default path. It does not deliver compliance on its own because the rules still have to be configured correctly, kept current, and governed by people who own the outcome.

That distinction is the whole point of this section. The value of encoding rules into the workflow layer is that it removes reliance on memory at the exact moments memory fails, under volume, and under pressure. But an interface that adapts to regulations is only as accurate as the regulatory logic someone loaded into it.

The workflow layer is a powerful control. It is not a substitute for a compliance program.

How to Audit a Vendor for CFPB Compliance

A vendor compliance audit is a structured review of whether a software provider’s product and operations genuinely support your regulatory obligations, backed by evidence rather than marketing claims.

Run it before you sign, and repeat a lighter version on a schedule, because certifications lapse and products change. Use the checklist below.

• Ask for the SOC 2 Type II report, not just a badge. Confirm it is current, read the scope, and check the exceptions section, which is where the real information lives.
• Confirm the specific Regulation F controls in a live demonstration. Make the vendor breach the seven-in-seven limit on screen and show you the system stopping it. Do the same for quiet hours and for an opt-out.
• Test the dispute workflow end-to-end. Watch a dispute arrive, land on the right account, trigger a hold, and generate a verification response, all without manual intervention.
• Verify retention behavior. Ask how the system meets the three-year retention obligation tied to collection activity, and how you retrieve one account’s complete history under time pressure.
• Check who owns the rule updates. Determine whether you can change compliance rules yourself, whether the vendor pushes regulatory updates, and how fast either happens when a law changes.
• Review the audit-log design. Confirm logs are complete, time-stamped, and tamper-evident, and that you can export them for an examiner or a court.
• Examine data security specifics. Encryption in transit and at rest, role-based access, and payment-data handling should be documented, not described in generalities.
• Read the contract for compliance responsibility. Understand exactly what the vendor commits to, what it disclaims, and where liability sits. Most vendors, correctly, will not warrant your compliance. That is the honest position, and it tells you the tool is a control, not a guarantee.
• Check references in your own regulatory context. Talk to a customer of a similar size and, ideally, in the same regulated sector, because a tool that suits a small agency may not survive a bank examination.
• Confirm state-law flexibility. Ask how the platform handles state overlays and new laws like California’s SB 1286, since federal rules are only part of your obligation.

If a vendor resists a live demonstration or cannot produce documentation, treat the silence as an answer.

A Short Note on the Vendor Landscape

Buyers often want a shortlist. It is more useful to understand the tiers. At the enterprise end sit platforms built for banks and large financial institutions, with deep configurability, strong security attestations, and the ability to handle complex, multi-product portfolios.

In the mid-market are agency-focused systems of record that manage accounts, payments, and communications for collection agencies and debt buyers.

A newer group of compliance-and-communications layers focuses specifically on Regulation F enforcement, consent management, and consumer self-service portals, often sitting alongside an existing system of record.

Names you will encounter across those tiers include established platforms and several fast-moving newer entrants. Rather than anchoring on a brand, match the tier to your situation: a single-state agency and a multinational bank have almost nothing in common in what “compliant software” needs to do. Evaluate against the requirements and the audit checklist above, not against a logo.

Frequently Asked Questions

Did CFPB rules change in 2026?

The core rule did not. As of mid-2026, Regulation F (12 CFR Part 1006), effective since November 30, 2021, remains in force, including the call-frequency presumptions, validation-notice requirements, and record-retention obligations. What changed is the enforcement environment. The CFPB has faced funding and legal challenges that slowed its enforcement and supervision activities. That is not the same as the rules going away. The FTC still enforces the FDCPA, consumers retain a private right of action, and states have been expanding their own protections. Plan around the rule as written.

Does compliant software make my agency compliant?

No. This is the single most important point for a buyer to internalize. Software enforces controls, generates required disclosures, and keeps records, all of which make compliance far easier and far more consistent. But compliance is a process that includes correctly configuring those controls, training staff, monitoring for problems, keeping rules current as laws change, and owning the outcomes. A platform can be perfectly capable and still be set up wrong. The vendor supports compliance. Your program governs it.

What is the difference between the FDCPA and Regulation F?

The FDCPA is the 1977 federal statute that prohibits abusive, deceptive, and unfair debt collection practices. Regulation F is the CFPB’s rule, effective November 30, 2021, that implements the statute with specific, operational detail, such as the seven-in-seven call presumption and the exact contents of a validation notice. In short, the FDCPA sets the principles and Regulation F sets the countable rules. Compliant software has to satisfy both.

How long do we have to keep collection records?

Regulation F requires retaining records that evidence compliance or noncompliance from the date you begin collection activity on a debt until three years after your last collection activity on that debt. Call recordings, where they exist, must be kept for three years from the date of the call. Because the clock is tied to collection activity rather than a fixed calendar, your software’s retention settings have to follow account activity, not a blanket schedule.

Do banks really need SOC 2 from a collection software vendor?

For most banks and larger financial institutions, yes, in practice. SOC 2, an independent examination against the AICPA’s Trust Services Criteria, is the common baseline of proof that a vendor’s security and data controls actually work over time. Many institutions add their own third-party risk reviews on top. A vendor without a current SOC 2 report will usually struggle to clear a bank’s procurement and risk process, regardless of how good the product looks.

Key Takeaways

1. A collection platform is part of your compliance posture, not separate from it. Under-built software becomes legal exposure the first time it lets an agent do something the rules forbid.
2. Split the obligation into two layers. The FDCPA sets principles; Regulation F, effective November 30, 2021, sets countable rules like the seven-in-seven call presumption and the validation-notice contents. Software has to serve both.
3. In 2026 the rules still apply even though federal enforcement has slowed. The FTC, private lawsuits, and expanding state laws keep the risk alive. Buy for the rule as written.
4. Require enforcement by design: frequency controls, quiet hours, consent and opt-out management, validation and dispute automation, suppression, immutable audit logs, and rules you can change without code.
5. Treat data retention as a legal requirement. Records must be kept from the start of collection activity until three years after the last activity, with call recordings kept three years from the call.
6. Demand independent proof of security. SOC 2 Type II, and often more for banks, is the evidence standard.
7. Audit the vendor with live demonstrations and documentation, not badges. If they cannot show a control working, assume it is not there.
8. No tool makes you compliant on its own. The software supports compliance; your program governs it.

The Bottom Line

Buying compliant collection software is really an exercise in reducing the distance between what the rules require and what your system does automatically.

The narrower that gap, the less you are relying on a tired agent at 8:55 p.m. to remember a rule, and the more you can prove, months later, that the rule was followed.

That is the real work: encoding the FDCPA’s principles and Regulation F’s specifics into the workflow, retaining the evidence for the years the rule demands, and proving the whole thing with independent security attestations.

Get the requirements and the vendor audit right, and the platform becomes what it should be, a control that makes the compliant path the default one. The judgment, the configuration, and the accountability stay with you, because that is where the regulators and the rules ultimately place them.