Vulnerable customer detection

A vulnerable-customer detection system interrupts an ordinary service path when an interaction shows signs of financial difficulty, cognitive strain, or possible coercion. It does not name a condition, freeze the account, or leave a medical-sounding label on the record.

The useful output is a specialist route plus a cite: channel, timestamp or message id, and the words or voice cues that triggered the flag. A vulnerable-customer or conduct specialist then decides what help, if any, is appropriate. If the cite cannot be replayed or read, the flag is not usable. The reviewer cannot tell whether the model reacted to a genuine cue, distress about a declined card, or a noisy transcript.

Keep the model out of diagnosis. A pause, a repeated question, or a third party prompting answers can justify a human look. None of that is a finding of dementia, mental illness, or incapacity. Do not store a medical conclusion the customer did not give. Do not write a condition name into the CRM because a classifier scored high.

Account restrictions stay a separate human decision. A detection score is not a reason to lock payments, block a card, or move the customer onto a reduced product. Those steps, if ever warranted, come after a specialist has spoken to the customer or an authorised representative, with a rationale that is not "the model said so."

Train the flag on observable behaviour, not a permanent customer type. Indicators worth a look include talk of going without essentials, confusion about a familiar product, inability to follow a simple confirmation, a new "helper" answering for the customer, or rehearsed language while the customer sounds frightened or checked out.

Financial difficulty often appears in servicing language: skip a payment, borrow to cover a bill, distress after a returned debit. That overlaps early arrears prediction, but the jobs differ. Arrears models estimate payment risk. This flag asks whether the person needs a different conversation before a standard collections script.

Coercion cues sit next to authorized push payment scam detection. A scam detector looks for a payment that should not go out. This detector looks for a person who may not be free to say no. The same contact can need both. Do not collapse them into one score that fraud treats as a block and a service queue treats as a vulnerability label.

Cognitive-strain cues are easy to over-read. Slow speech, requests to repeat, mixed-up dates, or trouble with a one-time passcode can mean a bad line, hearing difficulty, language, medication, or a bad day. Route them. Do not name a disease.

Contact-centre and core-banking platforms in the Salesforce and Temenos classes will hold cases, notes, and product state, and may supply NLP or voice scores. Treat those scores as signal sources. You still define which signals create a route, who receives it, what evidence travels with it, and what must never be written back to the customer record.

When a flag fires, pause the default script. Do not leave the customer in a bot trying to close the contact. Do not ask the frontline agent to run a clinical conversation. Open a short specialist work item: why it fired, the quotes or time-stamped audio spans, the journey in play (password reset, payment, limit increase, collections), and whether a third party was audible or typing.

Score the live contact. Overnight transcript batches can support quality sampling. They cannot help the person on the line. Give the specialist a player with timestamps or message ids and the trigger spans highlighted.

If an agent is already on the call, show the same cite through agent assist copilot as a prompt to slow down and offer a transfer, not as a banner that the customer is vulnerable. Suggested phrasing can offer extra time, a trained callback, or a wait while the customer fetches a trusted person already on file. It must not suggest a diagnosis or a product freeze.

The specialist checks the cite, speaks with the customer where possible, and chooses support: more time, another channel, a forbearance talk about the bill rather than the person, an internal referral, or a decision that the ordinary journey can resume. Support is what the customer agrees to, within policy. The flag does not create a standing restriction.

Record operational facts: interaction, quotes, specialist, what was offered, what was accepted. If the customer discloses a health condition in their own words, record that disclosure as given, under existing sensitive-data retention rules. Do not upgrade their wording into a clinical code the model invented.

Illustrative path: in a voice IVR a customer tries to raise a daily transfer limit. The speech model flags overlapping speech from a second person supplying answers, and the customer's delayed one-word confirmations. The system does not block the limit change from the score. It stops self-serve completion, queues a specialist callback with the two timestamps and transcript spans, and leaves the existing limit in place until a human has spoken to the customer alone, or has followed the process for a known authorised representative. If the second voice was a helpful partner, the specialist completes the request. If the cite looks like coercion, it is a conduct and fraud issue, not a medical file note.

tier-1 service deflection is where coercion and confusion are easiest to miss. A bot measured on containment keeps asking the next authentication question while the customer is distressed or coached off-mic. The journey never leaves the IVR or chat tree, so no specialist sees the cite.

Once a vulnerability or coercion indicator fires at the route threshold, containment is no longer a success metric for that contact. Escalate even if the bot could have solved the password or the payment. Getting a checkable conversation to a trained person comes first.

The same rule applies in arrears or a scam-like payment flow. Do not force the bot to choose between deflect, collect, and stop-the-payment as if those were mutually exclusive. Park the automated journey, pass the cite, and let the specialist sequence safety of the person, then the payment, then the account.

Locking the account from a score. A high vulnerability or cognitive score is not a basis to restrict the customer. An automatic lock can miss rent, medication, or wages, and you cannot defend it with a model output. If a restriction is needed, a named person authorises it against policy, with a review date.

Writing a diagnosis into the CRM. Labels such as "dementia," "mental health," or "lacks capacity," entered because a vendor feature fired, are medical conclusions the customer did not give. They leak into later agent behaviour, credit and collections, and subject-access responses. Store the cite and the specialist outcome. If reporting needs a code, use a process code (referred, extra support offered, extra support declined), not a health code.

Missing coercion because the bot held the customer in self-serve. If the only path out of the IVR is completing authentication, a controlling third party can complete it. A flag that cannot break containment is unused. Allow it to abandon the automated flow.

Do not let a route become a permanent type. Distress about a fee is common and can still deserve a look. A standing flag that follows the customer for years without a specialist decision and a review is a lasting label by another name. Time-limit it. The specialist closes it, converts it to an agreed support plan, or drops it.

Measure the specialist queue by whether the cite was usable and whether the outcome was a support decision, not by how often the model was right about a condition it is not allowed to name. Do not punish frontline staff for transferring.