Loan Servicing AI: Testing Verification and Balance Answers

Most inbound calls to a lender or BNPL provider are status calls. What do I owe? When is it due? Did my payment post? Is autopay on? Can I move my due date? A voice agent can answer all of these. It also creates a new kind of error. The answer sounds fluent and confident, and it is wrong by one digit, one day or one loan.

This guide is for the product team running that agent inside a lending or BNPL platform. Your agent serves borrowers across many merchants or loan programs. Every prompt change reaches all of them at once. Mortgage escrow questions live in our mortgage servicing post.

What a loan servicing AI call actually does

Loan servicing AI: a voice or chat agent that answers borrower questions about an existing loan. It verifies the caller, looks up the right account, reads figures from the ledger and records what happened.

That is an agentic workflow with a phone call at the front. Each status call runs five steps. The agent verifies identity. It resolves which account and which loan the caller means. It fetches ledger values with an as-of time. It speaks one or more amounts and dates. Then it writes back a note, a promise record or a change request.

Speech errors enter at every step, and they rarely crash anything. A misheard digit returns a different record, not an error. A stale balance returns a number, not a warning. A wrong amount in a note looks like any other note.

Multiple loans make lending and BNPL harder than a bank line. The CFPB's January 2025 BNPL report found that about 63 percent of borrowers "originated multiple simultaneous loans" during 2022. The data covers pay-in-four loans from six large providers. So "what's my balance?" often has three correct answers on your own platform. The agent has to ask which plan, or give a clear total, and say which one it chose.

Borrower verification: a ladder for lending and BNPL calls

Verification is a ladder, not a gate. Each rung unlocks a class of answers. Our credit union member verification guide covers factor design, lockouts and deepfakes in depth. Here is the version for a lending platform.

The FTC's Safeguards Rule sets the floor for non-bank lenders. 16 CFR 314.4(c)(1) says to "authenticate and permit access only to authorized users" before data is shared. Paragraph (c)(5) requires multi-factor authentication "for any individual accessing any information system." Paragraph (c)(8) requires logging the activity of authorized users. Ask counsel how these apply to a phone channel. Either way, your call logs are the evidence.

Wrong-account lookup from misheard digits and names

Digit strings are where speech recognition is weakest. In the digits micro-model paper, Chhablani et al. report a 5.8% error rate for OpenAI's Whisper on multi-digit recognition. Their small specialized model reached 1.8%. Peyser et al. (2019) showed end-to-end ASR also struggles with dollar amounts it rarely saw in training.

What matters is what your lookup does with a wrong digit. Here is an illustrative example. Say you have 2 million borrowers with last-four SSN digits spread evenly. About 200 borrowers share any given last four. If your tool matches on last four alone, a single misheard digit almost always lands on a real person. Add an exact date-of-birth match and the odds change. About 18,250 birthdates are plausible (50 birth years × 365). The chance that one of those 200 also shares the caller's birthday is about 200 ÷ 18,250, or 1.1%. The wrong digit now usually fails safely, with "no match."

Names are worse. "Ann Marie Lee" and "Annemarie Leigh" sound the same. A fuzzy search that returns the closest record turns a speech error into a privacy incident. So match exactly on two factors. If more than one record matches, re-ask; never pick one. For how to score these arguments, see our guide to tool-argument accuracy from speech.

Over-disclosure before verification

The most common leak comes in the first ten seconds. Caller ID matches a number on file. The agent greets the caller by name or mentions "your three plans" up front. Both disclose account data to whoever holds the phone.

BNPL adds a twist. Plan names often carry the merchant, which reveals a purchase. Treat merchant, item and amount as tier 2 data. Caller ID is a risk signal, not proof. Our PII leakage detection guide shows how to catch spoken leaks in transcripts and logs.

Third-party callers

Spouses call. Adult children call for a parent. Store staff call for a customer at the counter. Some callers are fraudsters. GLBA's pretexting provision is 15 U.S.C. 6821. It bars getting customer information through "a false, fictitious, or fraudulent statement or representation" to an institution's agent.

An unverified third party gets tier 0 answers only. An authorized user on file climbs the ladder under their own identity. A child who answers a parent's security questions is a core test case. The agent should ask who is calling before asking for any factor.

Balance, payoff and past-due: three numbers that sound alike

A borrower who asks "how much do I owe?" might mean four things. The CFPB's payoff explainer is direct: "Your payoff amount is different from your current balance." The payoff covers "any interest due through the day you intend to pay off your loan." It may also include unpaid fees.

Take a $240 pay-in-four plan after one payment. If the agent says "you owe one hundred eighty dollars," the caller may think it is all due now. The right answer names both: "Your next payment is $60, due November 3. The remaining balance on this plan is $180."

Worked example: the per-diem gap (illustrative)

Take an installment loan with $2,400.00 remaining at 24.99% APR, simple daily interest. These numbers are illustrative.

daily interest = 2400.00 × 0.2499 ÷ 365 = $1.643 per day
payoff quoted good-through Oct 16:   $2,400.00 + accrued interest
borrower pays on Oct 21:             5 days later
shortfall = 5 × 1.643 = $8.22

An $8.22 shortfall leaves the loan open. Next month the borrower gets a bill on a loan they think is closed. So the payoff tool returns a good-through date, and the agent says it. A correct answer sounds like this: "Your payoff is $2,412.88 if we receive it by October 16." Dropping the date makes it wrong.

Pending payments and "did my payment post?"

The caller paid yesterday, and the ledger shows it as pending. If the agent skips the pending item, the caller hears the old number. Some will pay again. The balance tool should return pending items with an expected posting date. The agent says both: "I see a $150 payment from October 14. It's pending and should post by October 17." Test this with a seeded pending payment in every regression run.

Rounding and number read-back: "fifteen" vs "fifty"

Numbers break in both directions. On the way in, speech recognition can confuse "fifteen" and "fifty" because they differ by one stressed syllable. On the way out, text-to-speech can read the right digits the wrong way.

In Gorman and Sproat (TACL 2016), a neural model read 9801 as "nine thousand seven hundred and one." The authors call that "completely unacceptable" for speech. ElevenLabs' normalization guide gives a vendor example as of October 2026. Eleven Multilingual v2 reads "$1,000,000" as "one million dollars" correctly. Eleven Flash v2.5 reads it as "one thousand thousand dollars" instead. ElevenLabs notes the better model may not suit low-latency uses such as conversational agents.

Three rules keep amounts safe:

1. Format amounts in code, not in the LLM. The tool returns cents. A formatter turns 15020 into "one hundred fifty dollars and twenty cents." The model inserts that string, unchanged.

2. Confirm teen and ty values by digits. If the caller says "fifteen," the agent confirms "one five, fifteen?" before using it for a factor or a promise amount.

3. Never round a payoff. "About twenty-four hundred" is not a quote.

Transcripts can hide these errors too. In the Careless Whisper study, about 1.4% of Whisper API transcriptions had hallucinated phrases. Speakers with long pauses saw more. A judge that reads only a transcript can score a call as correct when the audio said something else. That is why Evalgent evaluates from the call audio, not only the transcript.

Why a wrong amount is a UDAAP problem

Under 12 U.S.C. 5531, the CFPB can act against any "unfair, deceptive, or abusive act or practice under Federal law" in consumer finance. A wrong payoff that leaves a loan open harms the borrower. A balance that omits a pending payment can mislead them. Neither needs bad intent.

Automation does not shift the duty. The CFPB's 2023 chatbot issue spotlight warns that inaccurate information "could be catastrophic." BNPL teams should note one change. The CFPB's BNPL compliance page records it: "On May 12, 2025, the CFPB withdrew several guidance documents, including the 2024 BNPL Interpretive Rule." That withdrawal changed guidance, not the statute.

This is general information, not legal advice. Confirm how these rules apply with your own counsel.

Delinquent accounts: where FDCPA and Regulation F come in

An originating lender's own status calls are usually not FDCPA debt collection. The "debt collector" definition in 15 U.S.C. 1692a(6) excludes debt "originated by such person" and debt not in default when obtained. Servicing accounts that were already in default when you got them is different. Regulation F then applies. Its third-party rule is 12 CFR 1006.6(d)(1). A debt collector "must not communicate, in connection with the collection of any debt, with any person other than" the consumer and a short list of others. For this rule, "consumer" includes a spouse and an estate's executor. So the third-party script must branch on account status. When the call turns into a payment plan, use our payment arrangement audit for FDCPA risk.

The write-back: notes, promises and due-date changes

The call ends; the record stays. Typical writes are a note, a promise to pay, a due-date change request, an autopay change or a dispute flag. This is where speech errors become permanent. The borrower said "fifteen," the agent heard "fifty," and the promise record reads $50. Collections acts on it. Nobody replays the audio unless the borrower complains.

Here is a simplified checker for one call. It flags three things. Amounts spoken before verification. Amounts that match no ledger value. A promise that differs from the confirmed amount.

import re

UNITS = {w: i for i, w in enumerate(
    "zero one two three four five six seven eight nine ten eleven twelve "
    "thirteen fourteen fifteen sixteen seventeen eighteen nineteen".split())}
TENS = {w: 10 * i for i, w in enumerate(
    "_ _ twenty thirty forty fifty sixty seventy eighty ninety".split()) if w != "_"}
NUM_WORDS = set(UNITS) | set(TENS) | {"hundred", "thousand"}

def words_to_int(words):
    total, cur = 0, 0
    for w in words:
        if w in UNITS: cur += UNITS[w]
        elif w in TENS: cur += TENS[w]
        elif w == "hundred": cur *= 100
        elif w == "thousand": total, cur = total + cur * 1000, 0
    return total + cur

def spoken_amounts(text):
    """Dollar amounts (in cents) in one agent utterance."""
    t = text.lower().replace("-", " ").replace(",", "")
    found = [round(float(m) * 100) for m in re.findall(r"\$(\d+(?:\.\d{2})?)", t)]
    w = "|".join(NUM_WORDS)
    pat = rf"((?:(?:{w})\s+)+)dollars?(?:\s+and\s+((?:(?:{w})\s*)+)cents?)?"
    for d, c in re.findall(pat, t):
        found.append(words_to_int(d.split()) * 100 + (words_to_int(c.split()) if c else 0))
    return found

def check_call(turns, ledger, writeback):
    issues, verified = [], False
    allowed = set(ledger.values())
    for t, spk, text in turns:
        if spk == "tool" and text == "verify:pass":
            verified = True
        if spk != "agent":
            continue
        for cents in spoken_amounts(text):
            if not verified:
                issues.append((t, "amount_before_verification", cents))
            elif cents not in allowed:
                issues.append((t, "amount_not_in_ledger", cents))
    p = writeback.get("promise_amount_cents")
    if p is not None and p != writeback.get("confirmed_cents"):
        issues.append(("writeback", "promise_mismatch", p))
    return issues

ledger = {"next_installment": 15020, "past_due": 15020, "payoff_today": 61288}
turns = [
    (2.1, "agent", "Hi Dana, I can see a past-due amount of $150.20."),
    (9.8, "tool", "verify:pass"),
    (14.0, "agent", "Your next payment is fifty dollars and twenty cents, due November third."),
    (21.5, "agent", "Your payoff today is six hundred twelve dollars and eighty eight cents."),
]
print(check_call(turns, ledger, {"promise_amount_cents": 5020, "confirmed_cents": 15020}))

Output:

[(2.1, 'amount_before_verification', 15020), (14.0, 'amount_not_in_ledger', 5020), ('writeback', 'promise_mismatch', 5020)]

All three flags fire. "Hi Dana" before verification is also a name leak; add a name check for it. In production, build `ledger` from the tool response logged during the call, not today's ledger. Otherwise a payment that posted later makes a correct answer look wrong. For more on failures that never raise an error, see how to detect silent tool failures.

The loan servicing AI test matrix

Test cases need two axes: the scenario (request plus account state) and the condition (how the caller sounds). Evalgent generates scenarios from your agent's prompt and flows. It then runs them with caller profiles that vary accent, speech pace, interruptions, background noise and language. Calls reach your agent over PSTN, SIP or WebRTC, so the phone path is tested too.

Run each scenario under four conditions: clean line, fast accented talker, street noise and an interrupting caller. Add Spanish runs if your borrowers call in Spanish.

How many runs prove it works?

Twenty clean calls prove little. Use the rule of three: zero failures in n runs puts the 95% upper bound near 3 ÷ n.

0 failures in 30 runs   → true rate could still be ~10%
0 failures in 100 runs  → ~3%
0 failures in 300 runs  → ~1%

To claim under 1% wrong amounts for one scenario family, you need about 300 clean runs across conditions and programs. Only automated simulated calls get there on every change. Our guide to voice agent testing in financial services covers how to split these runs across lines of business.

Monitoring loan servicing AI across every program

Tests cover the cases you thought of. Production shows you the rest. Score every live call, or a large sample, on these metrics.

Break each metric out by loan program. A change that works for 36-month loans can break pay-in-four plans. Evalgent's production monitoring transcribes pushed call recordings, maps each to a scenario and judges it. It flags PII leakage, tool-call failures, latency spikes and policy failures, with fix recommendations. For the general setup, read how to monitor voice agents in production. If your agent also places outbound calls, the sibling post on mortgage AI calls and TCPA handoff checks covers consent and transfer tests.

How to test a loan servicing AI voice agent before a change ships

1. Write down the ladder. Map every request type to a tier. Enforce it in the tool layer, not just the prompt.

2. Make lookups exact. Two exact factors; return "no match" or "multiple," never a closest record.

3. Return typed figures from tools. Each amount comes back in cents with a type (balance, payoff, past-due, installment) and an as-of or good-through date.

4. Format amounts in code. Insert pre-formatted spoken strings. Confirm teen and ty values by digits.

5. Seed test accounts. Include multi-plan BNPL borrowers, pending payments, past-due accounts and accounts already in default.

6. Run the matrix on every change. Four caller conditions, over a real phone path. Aim for 300 runs per high-risk family before a major release.

7. Diff the write-back. After each run, compare the saved note or promise with the confirmed amount and date.

8. Monitor by program. Alert on any pre-verification disclosure or wrong-account pull. Turn each failure into a test.

For a broader policy test library, see our compliance test cases for regulated voice agents.

Frequently asked questions

Can an AI voice agent give a loan payoff amount over the phone?

An AI voice agent can quote a loan payoff amount after the caller passes verification. The amount must come from the servicing system, not the model. It should include interest through a stated good-through date and any unpaid fees. The agent should say that date out loud, because a payoff paid later will be short by the daily interest.

What is the difference between current balance and payoff amount?

The current balance is what you owed at the last posting. The payoff amount adds interest through the day you plan to pay, plus any unpaid fees. The CFPB states plainly that the two are different. A voice agent that reads the balance as a payoff leaves the loan open with a small remaining amount.

How should a lending voice agent verify a borrower's identity?

A lending voice agent should use a ladder. General questions need no verification. Account-specific answers need at least two factors matched exactly, such as date of birth and the last four of the SSN. Changes like a new due date or autopay change need a one-time passcode to a device on file. Caller ID alone is never enough.

What does the FTC Safeguards Rule require for authentication?

The FTC Safeguards Rule, 16 CFR 314.4, requires access controls that "authenticate and permit access only to authorized users." It requires multi-factor authentication for anyone accessing an information system. A qualified individual can approve comparable controls in writing instead. It also requires monitoring and logging of authorized users' activity. Ask counsel how this maps to your phone channel.

Can a voice agent talk to a borrower's spouse about the loan?

A voice agent should treat a spouse who is not on the account as a third party. Give general information only, and explain how the borrower can call or add an authorized user. Pretexting is barred under 15 U.S.C. 6821. For debt collectors, Regulation F counts a spouse as the consumer for third-party contact rules, so policy can differ by account status.

Why does a voice agent say fifteen when the amount is fifty?

A voice agent can mix up "fifteen" and "fifty" in two places. Speech recognition can mishear the caller, because the words differ by one stressed syllable. Text-to-speech can also misread a number the model wrote out. Fix both by formatting amounts in code from cents and by confirming teen and ty values digit by digit.

Does FDCPA apply to loan servicing AI calls?

The FDCPA usually does not cover an originating lender's own status calls. Its "debt collector" definition excludes debt the person originated and debt not in default when obtained. It can apply when your platform services accounts for others that were already in default when acquired. Then Regulation F rules on third-party contact and disclosures apply to those calls.

How do you test a loan servicing AI voice agent?

Test a loan servicing AI voice agent with seeded accounts and scripted callers over a real phone path. Cover single and multi-plan balances, payoffs, pending payments, past-due amounts, due-date changes and third-party callers. Run each under clean, accented, noisy and interrupting conditions. Compare every spoken amount with the logged tool response, and diff the saved note.

The bottom line

Loan servicing AI goes wrong when a speech error turns into a confident answer about the wrong account, the wrong figure or the wrong date. Prevent it with exact two-factor lookups, amounts formatted in code, a test matrix on every change and live scoring by program.