AI Agents for Collections and Lending in 2026: Compliance, Integrations and Vendors Compared

AI agents for collections can support bounded tasks such as payment reminders and basic account information, but channel coverage varies by vendor and configuration. A defensible deployment needs workflow-specific consent, contact limits, disclosures, escalation, record retention, system-of-record access, and human approval before a changed workflow reaches production. Decagon documentation and a 2025 NBER study illustrate the distinction between limited automation and consequential collection work.

Disclosure: NuPlay AI builds a competing enterprise AI platform. We reviewed public product documentation and vendor-published case studies available as of September 30, 2026. We did not run hands-on trials, and this comparison does not mean any vendor is regulator-approved.

What are AI agents for collections?

AI agents for collections are software systems that use approved business rules, account context, and connected systems to support collection or lending tasks. An agent may retrieve approved account information, perform a permitted workflow action, record a disposition, and transfer an interaction with context. It should not independently set policy or replace defined human review.

The strongest initial use cases are bounded and repeatable:

• Retrieving account or payment status
• Sending approved reminders
• Authenticating a borrower
• Answering basic due-date or payment-method questions
• Scheduling a callback
• Recording a disposition
• Routing disputes, hardship requests, wrong-party contacts, and exceptions

A 2025 working paper from the National Bureau of Economic Research (NBER) by James J. Choi, Dong Huang, Zhishu Yang and Qi Zhang, “How Good is AI at Twisting Arms? Experiments in Debt Collection,” studied calls to delinquent borrowers at a leading online consumer-finance company in China. The researchers found AI callers substantially less effective than human callers: borrowers first contacted by AI had repaid 1% less of the initial late payment a year later. Replacing AI with human callers six days into delinquency closed much of the gap. It is a working paper circulated for discussion, not a peer-reviewed study, and it covers one Chinese lender, so it does not show that every collection deployment will produce the same result. It does support a design that escalates difficult persuasion, hardship, and exception cases to people. NBER working paper

That distinction matters. A chatbot may answer a question, and a dialer may place calls, but an agent can operate across a defined workflow. The workflow still needs limits on what the agent can disclose, change, promise, or write back to a system of record.

The practical decision rule is:

Automate retrieval, reminders, authentication, status requests, and routing first. Keep hardship assessment, loss-mitigation determinations, disputes, exceptions, and consequential credit decisions under defined human review.

Compliance is a workflow architecture, not a vendor badge

A provider can supply collection-capable technology, but you should assess compliance at the configured workflow level. The assessment depends on your role, debt type, jurisdictions, channels, consent records, policies, and escalation design. The Consumer Financial Protection Bureau (CFPB) mortgage-servicing examination procedures direct examiners to assess a regulated entity’s compliance risk-management systems, internal controls, policies, and procedures. Buying software does not transfer that responsibility.

First-party and third-party collection activity

Regulation F implements the Fair Debt Collection Practices Act (FDCPA) for entities that meet the definition of a debt collector. It covers communications, validation information, disputes, time-barred debt, and record retention.

The CFPB’s mortgage-servicing procedures explain that the FDCPA generally applies to third parties collecting debts for lenders after default, as well as lenders collecting under an assumed name. A first-party creditor workflow still needs legal review under the laws and rules applicable to the lender’s activity. Do not treat a workflow as outside review simply because the lender is contacting its own borrower.

Contact limits apply across channels

Regulation F’s telephone-call presumption does not make a multichannel campaign safe by default. The CFPB states that harassment can be assessed from the cumulative effect of conduct across telephone calls, email, text messages, social media, and other media. A campaign that stays within one call-frequency threshold may still create risk when its calls, texts, and emails are viewed together. CFPB Regulation F section 1006.14

Your campaign design should therefore maintain a single contact history across channels. It should also enforce:

• Consent and revocation status
• Wrong-party and opt-out flags
• State and local timing rules
• Contact-hour restrictions
• Attempt caps and cadence
• Suppression after a dispute or cease-contact request
• Human review for exceptions

The call-frequency presumption is specific. A debt collector is presumed to violate Regulation F if it calls a person about a particular debt more than seven times within seven consecutive days, or within seven consecutive days after a telephone conversation about that debt (12 CFR 1006.14(b)). Calls must also meaningfully disclose the caller’s identity (1006.14(g)).

The same workflow carries other timed and scripted duties for entities that meet the definition of a debt collector. Contact before 8:00 a.m. or after 9:00 p.m. local time at the consumer’s location is presumed inconvenient, and each email or text must include a simple opt-out method (1006.6). The initial communication must say the collector is attempting to collect a debt and that information obtained will be used for that purpose, including when the consumer starts the call (1006.18(e)). An agent’s greeting and scripts are where these duties live.

Recording is not automatically required

Regulation F does not require every collection call to be recorded. If a debt collector records collection calls, however, the collector must retain each recording for three years after the call date. Other records that evidence compliance or noncompliance must be kept until three years after the debt collector’s last collection activity on the debt, which can include call logs and communications.

Regulation F does not address whether a call may be recorded in the first place. Ask how the workflow handles recording notice and consent where state law requires it, and have counsel confirm. CFPB Regulation F section 1006.100

Ask each vendor to distinguish between:

1. Whether calls can be recorded
2. Where recordings are stored
3. How long they are retained
4. Whether transcripts and metadata are retained
5. Whether retention can vary by jurisdiction or workflow
6. Whether your team can export the evidence

AI voice calls require counsel review

The Federal Communications Commission (FCC) has determined that AI-generated voices are “artificial” under the Telephone Consumer Protection Act (TCPA). That does not mean every AI voice call is categorically unlawful. Consent, revocation, caller identification, campaign purpose, applicable state law, and call design still require review for the specific program. FCC announcement

Treat the TCPA as a customer obligation and evaluation criterion, not as a vendor certification. The same principle applies to other legal requirements that may apply to the lender, servicer, creditor, or debt collector.

Minimum evidence pack

Before production, require an evidence pack that includes:

• Consent, revocation, and opt-out records
• Contact history and suppression logic
• Disclosure versions and approval history
• Transcripts or recordings where used
• Agent actions and application programming interface (API) write-backs
• Authentication events
• Escalation reasons and human-assistance records
• Retention settings and deletion behavior
• Policy versions active during each interaction
• Exportable logs that connect the interaction to the account and disposition

A vendor may document that a feature exists. You still need to verify that the feature is enabled, configured for your policies, and available in an export that your compliance and examination teams can use.

Which vendors have documented public evidence?

The useful comparison is not a ranking of the “best” AI collections software. It is an evidence check. Separate what a vendor documents publicly, what the vendor claims about its own product, and what remains unverified until a buyer completes a demo, security review, and workflow test.

This table separates documented evidence, vendor claims, and information that is not publicly verifiable. It is not a certification or performance ranking.

Decagon publicly documents payment-reminder outreach by call and text. Sierra publicly describes overdue-payment collection as a Horizon use case. Neither reviewed source publicly verifies a specialist payment-arrangement automation product. Do not imply that either vendor can independently negotiate, approve, or execute payment arrangements without buyer-specific workflow evidence. Decagon source Sierra source

The same evidence standard applies to every option:

• Documented: The product documentation describes the capability or integration.
• Vendor claim: The vendor presents the capability or outcome, but the reviewed material is not independent validation.
• Not publicly verifiable: The reviewed material does not establish the capability for your workflow.

For example, a vendor-published case study can show that a deployment exists. It does not prove that the same controls, integrations, retention settings, or outcomes will apply to your organization.

Mortgage servicing: what should survive CFPB scrutiny?

Do not ask whether a vendor is “CFPB-approved.” Ask whether the servicer can demonstrate workflow controls, system-of-record access, human escalation, and reproducible evidence for the specific servicing use case. The CFPB mortgage-servicing procedures organize examination work around areas including payment processing, consumer inquiries, collections, bankruptcy, loss mitigation, continuity of contact, and foreclosure.

Separate low-risk inquiries from high-risk decisions

Payment-status and escrow inquiries may be suitable for controlled automation when the agent authenticates the borrower, retrieves current data, provides approved information, and records the interaction.

Loss mitigation carries a different risk profile. Regulation X requires a servicer to exercise reasonable diligence in obtaining information needed to complete a loss-mitigation application. Under Regulation X section 1024.41, a borrower’s inquiry can become an application when the borrower expresses interest in a loss-mitigation option and provides information the servicer would evaluate. The workflow must identify that transition and route it correctly.

A sensible division is:

A vendor-published Decagon case study states that Valon deployed Decagon voice agents for inbound mortgage-servicing calls and reports more than 50% voice deflection. That is public deployment evidence and a vendor-published outcome, not independent evidence of regulatory compliance. It does not establish that every servicer can reproduce the result or that the deployment covers loss-mitigation determinations.

Integration reality: Encompass, Blend, and MSP

Public evidence confirms an Encompass-to-MSP integration and a direct Blend-to-Encompass integration. It does not establish that an independent AI-agent vendor has a native, production-ready connector for all three systems.

The reviewed documentation shows:

• MSP and Encompass: MSP documentation describes API-based loan boarding from Encompass into MSP, including data and document transfer, comparisons, exception handling, and post-boarding audit. MSP-Encompass integration
• Blend and Encompass: Blend documents a direct integration that includes eFolder disclosure delivery and real-time transaction notifications. Blend-Encompass integration
• MSP servicing agents: The MSP provider announced voice and chat agents for servicing in beta in March 2026. The announcement describes integration with MSP for questions about escrow, private mortgage insurance, servicing transfers, payments, and autopay enrollment. Treat beta status as material in procurement. March 2026 announcement

A logo on an integration page is not enough. Require a live demonstration of one real borrower workflow that shows:

1. Authenticated read access to the system of record
2. Permitted write-back for an approved action
3. Failed-write handling and retry behavior
4. Identity continuity when the interaction transfers to a person
5. Event logs connecting the agent action to the account
6. Policy and disclosure versions active during the interaction
7. Replayable evidence for why the workflow proceeded, stopped, or escalated

Also ask whether the connection is native, partner-built, API-based, batch-based, or dependent on custom middleware. These distinctions affect the evidence you can retrieve and the operational work required when a system changes.

Worked example: overdue mortgage-payment workflow

The following is a hypothetical implementation template, not a claim about any vendor’s current product.

1. The servicing system identifies an overdue payment.
2. An eligibility service checks consent, state rules, contact history, active disputes, bankruptcy, cease-contact flags, and existing escalations.
3. The agent sends only an approved outreach within configured timing and channel rules.
4. The agent authenticates the borrower before disclosing loan information.
5. The agent can provide approved balance, due-date, payment-method, and payment-link information.
6. A hardship, loss-mitigation, dispute, wrong-party, or human-assistance request ends the automated resolution path and creates a routed case with the transcript, reason code, and account context.
7. The system of record receives the disposition and linked evidence.

Success checks

Testing should establish that:

• No prohibited contacts occur
• Suppression rules work across every channel
• Every escalation creates a traceable case
• Supervisors can reproduce why outreach occurred or was suppressed
• Authentication status transfers correctly to a human
• Failed writes do not produce a false confirmation
• The account record receives the correct disposition
• Policy changes move through documented approval before production

For buyers comparing operating models, ask how changes are tested and approved after launch. NuPlay runs enterprise workflows in production and improves them after every run through NuLoop, with agents, the systems they operate, and the context they draw on under one platform. In its approve-to-promote mode, NuLoop follows Report, Diagnose, Propose, Try, Ship, and a human signs off before a change is promoted. This is a governed-change model, not permission to let an agent change collection policy without review.

To map one collections or servicing workflow to an enterprise agent design, book a demo.

Where NuPlay fits

NuPlay runs enterprise workflows in production and improves them after every run through NuLoop, with agents, the systems they operate, and the context they draw on under one platform.

Include NuPlay in a collections or lending evaluation when the workflow spans agents, the servicing systems they act on and the context they share, and when every change to that workflow needs a human sign-off before it reaches production. Talk to the team about one borrower workflow and ask to see it run end to end, including the exception path.