In collections and payments, the conversation design is the compliance work. How to set guardrails on promises, detect vulnerability, keep audit trails and measure outcomes that matter more than containment.
In most chatbot projects a bad answer is an annoyance. In collections and payments it can be a regulatory breach, a formal complaint, or real harm to someone already under financial pressure. That changes how almost everything should be designed. The most common mistake I see is treating compliance as a filter bolted on after the conversation design is finished. In regulated conversations, the conversation design is the compliance work, and the teams that accept this early ship faster, because they stop rebuilding flows after every legal review.
I led product for conversational AI in collections and payments, for large enterprise clients in an ISO 27001-certified environment. What follows are the design rules I would hand to any team starting in this space, whether they use a language model, a scripted flow, or both.
Rules for debt collection and consumer credit generally care about how things are said, not only what is said. Implying consequences that will not happen, creating false urgency, applying pressure, or being unclear about amounts and fees can all be breaches on their own. "Your account may be passed to our legal team" is a misrepresentation if that is not actually going to happen. "You need to pay today" can read as pressure even when the intent was helpful.
This is where generative models create a specific risk. A model that paraphrases freely will, over thousands of conversations, drift toward phrasings nobody approved. Most of them will be fine. A few will not, and those few are what a regulator or an ombudsman will read.
The rule I apply is simple. Identify the categories of regulated statement (amounts, dates, fees, consequences of non-payment, customer rights, and any commitment by the business) and make sure the model never authors them. It may choose among approved phrasings, fill verified values into them, and handle the surrounding conversation: acknowledging what the customer said, clarifying a question, explaining a step in plain words. The regulated sentence itself comes from a template that compliance has signed off.
Separate talking from committing. An assistant that can say "I can freeze interest on your account" because the conversation seemed to call for it is an assistant that will eventually say it to someone who does not qualify.
Every commitment (accepting an arrangement, waiving or freezing charges, pausing contact, changing a due date) should come from a deterministic policy service that the assistant calls as a tool. The assistant may only state a commitment that the system of record has returned. My shorthand for this is that the model proposes, the rules decide, and the template speaks. If the policy service is down, the assistant does not improvise. It says it cannot confirm that right now and offers a human or a callback.
A meaningful share of people in collections are dealing with something beyond the debt: illness, bereavement, job loss, mental health difficulties, caring responsibilities, or simply confusion about what they owe. Many will not say so directly. They will say things have been hard lately, or that they are sorting out a parent's affairs, or they will stop replying halfway through.
Design detection for recall, not precision. A false positive costs a conversation with a trained human. A false negative can cost a person real harm and the business a serious complaint. Tune for that, even though it lowers containment and adds load on agents. Whoever owns the cost model will push back. It is still the right call.
Escalation must be a real handoff. Sending a vulnerable customer a phone number and opening hours is not escalation, it is a dead end with a polite tone. A proper handoff passes context to the agent so the customer does not have to repeat a painful disclosure, and it offers a channel the customer can actually use at that moment. Finally, the assistant should not diagnose. Its job is to notice, respond with care, ask permission to record what was shared, and hand over.
When a complaint arrives months later, someone will need to reconstruct exactly why the assistant said what it said. That means logging more than the transcript. For each turn you want the model and prompt version, the policy rules and templates in force, every tool call with its inputs and outputs, the decision the system made, and the reason code for it.
Coming from an information security audit background, I would add two requirements that teams often skip. Logs must be tamper-evident, and access to them must be controlled and itself logged, because these records contain exactly the sensitive data you are trying to protect. Retention should follow a written policy rather than whatever the storage default happens to be.
Before discussing a debt, verify identity. A message on a shared phone or a family laptop can disclose a debt to a third party, which is a breach in itself. Verification should happen before any account detail appears, including the creditor's name if that alone reveals the nature of the debt.
Then collect only what the task needs. An affordability check for a payment arrangement may need income and essential outgoings. It does not need a full life story, and it certainly does not need that story copied into an analytics warehouse. Redact or tokenize personal data before it reaches the model where you can, keep vulnerability information in a separate store with tighter access, and record explicit consent for contact channels and for keeping notes about circumstances.
Treat the policy manual as a source of test cases. Each rule becomes a set of scenarios, including adversarial ones: a customer pushing for a promise the assistant cannot make, a customer disclosing vulnerability obliquely, a third party who has picked up the phone, a customer who disputes the debt. Compliance writes or reviews these scenarios with product, and the full suite runs on every change to prompts, templates, models or policy rules.
Automated checks catch structure, such as whether identity was verified and the approved template used. Human review of sampled conversations catches tone. You need both, with the human sample weighted toward conversations that ended in escalation, complaint or a broken arrangement.
Take a hypothetical lender whose assistant contacts a customer by text after a missed loan payment. The customer replies and passes identity verification. The assistant states the arrears using the approved template, with the amount pulled from the system of record.
The customer writes: "I lost my job last month. Can I pay less for a while?" That is a vulnerability signal and a request for an arrangement. The assistant acknowledges it plainly and offers a choice: continue here with a short check of income and essential costs, or speak with a person. The customer chooses to continue.
The assistant asks only what the affordability check requires. The policy service returns the arrangements the customer qualifies for, and the assistant presents them using templates that state the monthly amount, the start date, the total period, what happens if a payment is missed, and how to change the plan later. The customer asks: "Will this stop the interest?" The policy response does not include a freeze, so the assistant does not improvise. It says it cannot confirm that here and offers a callback from someone who can review it. The customer accepts the arrangement and the callback. A written confirmation follows, and the audit record holds every step, including the vulnerability flag and the customer's consent to note it.
The failure modes to design against in that same conversation:
Containment rate is the number most vendors lead with, and on its own it rewards exactly the wrong behavior. An assistant that never escalates will contain beautifully while setting up arrangements that break and missing people who needed help.
Measure what the business and the regulator both care about. Arrangement kept rate over the following months, not just arrangements created. Whether escalations happened when they should have, judged by sampled review. Complaint rate and complaint themes. Repeat contact on the same issue. Whether customers received and understood written confirmation. Containment still belongs on the dashboard, but as one number among several, and a sudden rise in it should prompt a check rather than a celebration.
If your assistant answers general questions about opening hours or how to download a statement, most of this is excessive. The weight of these controls belongs where the assistant discusses money owed, makes commitments, or talks to people who may be struggling. There is also a fair counterargument that heavy templating makes the assistant stiff. It does, a little. The answer is to give the model room in acknowledgment and clarification, where warmth matters most, and to keep it away from the sentences that carry legal weight.
If you are starting this week, take one live flow, list every regulated statement it makes, and check whether each one comes from an approved template or from the model. That list will tell you how much of your compliance currently rests on luck.
Written by
Ratomir Jovanovic
Approval rates, retries, failure messages, fees and reconciliation shape revenue and customer trust directly. That makes payments a product area with an owner, metrics and a roadmap.
12 August 2026
Most LLM features that disappoint in production were judged badly, not built badly. A practical evaluation process for product leaders: job definition, golden sets, failure taxonomy, budgets and a ship/no-ship rule.
8 July 2026
A product leader can now put a working prototype in front of users in days. The long PRD should shrink to a decision memo plus a prototype, with clear rules on what the prototype proves and what it does not.
9 June 2026