Automated Debt Collection SMS Setup: Consent, Tone and Record Keeping

A collection reminder is the message category most likely to be scrutinised and the one most likely to be automated badly. It is a regulated contact, it goes to someone who may already be under stress, and it produces a record that a dispute may turn on.

This article sets out why the category carries stricter expectations than ordinary notification, what may and may not appear in a message, how contact preferences and frequency caps are handled, and what the record has to show.

Why does an automated debt collection SMS setup carry stricter expectations?

Because the recipient has not chosen the conversation.

A collection message arrives because a payment is outstanding, and that context changes what counts as acceptable contact, at what hour, and how often.

Three consequences follow. The content is restricted, because a message that discloses a debt to whoever sees the device is a harm in itself. The contact is restricted, because repeated contact at unsuitable hours is a recognised problem that regulators have addressed in most markets. And the record is scrutinised, because a dispute often turns on whether a specific message was sent, when, and to whom. None of those three are technical requirements, and all three shape the technical design.

The rules differ by market and change over time, which is why this article describes the structure rather than quoting thresholds. Numeric conventions circulate in this sector, including rules of thumb about calls within a period, and any figure you encounter should be treated as something to verify with the applicable regulator or counsel rather than to design to. Where the processing falls within the European framework, the reference points are the regulation on EUR-Lex and the guidance collected by the European Data Protection Board.

Dimension	Why it is restricted	What the design has to do
Content	The message can be read by anyone holding the device	State the action, not the debt
Frequency	Repeated contact is itself the harm	Enforce a cap in the platform
Timing	Contact at unsuitable hours	Restrict the send window per market
Record	Disputes turn on what was sent	Per-message record with the identifier

What may and may not appear in a message?

State the action, and nothing that identifies the reason.

A message that says a payment is due identifies a debtor to whoever reads the screen, which is the disclosure the category is designed to avoid.

The safer pattern names the sender organisation and asks the recipient to contact them, without naming an amount, an account, a product or the reason. A reference number is acceptable where it is meaningless to anyone else. The message should avoid any wording that could be read as a threat or as a prediction of consequence, and it should avoid implying that a decision has already been taken if it has not. Those are tone requirements rather than legal ones, and they are the ones that generate complaints.

Two further exclusions are worth enforcing in the platform rather than in a template. A message should not include a link that the recipient is expected to act on without being able to verify the sender, because the pattern is indistinguishable from a phishing message and damages both the sender and the channel. And replies should not be invited where the reply channel is unmanaged, because a reply that arrives in an unmonitored inbox is a message that may contain information the organisation is not permitted to hold. The message framework that carries the notification is defined in ETSI TS 123 040.

Consent and contact-preference handling

Preference is a set of channels and times, not a single switch.

Recipients commonly have a view about being contacted by message, by call, or at particular hours, and that view should be recorded as a preference rather than inferred.

The record should capture the channel the recipient accepts, the hours they accept being contacted in, and any channel they have expressly asked to be left alone on. Where a recipient has asked for no messages, the suppression must be immediate, must apply to every sending path, and must survive a change of platform. A suppression that lives in one system is a suppression that a second system will ignore, which is the most common compliance failure in this category.

The engineering contribution is to make the preference enforceable at the point of sending. The platform should refuse to send when the category and the time fall outside what the recipient has accepted, and it should log the refusal, because a refusal is evidence that the control exists. Where the deployment uses several numbers for rotation, the preference must be held against the recipient rather than against the number, or a debt will be contacted twice from two different numbers in the same day. The numbering conventions behind the recipient record are described in ITU-T E.164.

Frequency caps and escalation paths

Both belong in the platform, and both need a ceiling.

A cap limits how many messages one recipient may receive in a period, and an escalation path defines what happens when the first message produces no response.

The cap should be expressed per recipient per period rather than per campaign, because a recipient does not experience campaigns; they experience contact. Where several departments or systems send to the same person, the cap has to be shared across all of them, which is a design requirement for the hub rather than for the individual sender. Walking through what the recipient experiences, rather than what each sender sends, is the test that reveals whether the cap is real.

The escalation path should be defined in advance, with a limit at each step. A reminder, a second reminder, and then a different channel is a common shape, and it should have an end state which may be a call, a letter or a decision to stop. An escalation path with no terminal step produces a program that will contact someone indefinitely, which is the pattern most likely to be characterised as harassment. The record of which step was taken, and when, is what demonstrates that the path was followed.

Time-of-day rules

Hours are local to the recipient, not to the sender.

Contact outside acceptable hours is a recognised problem, and the hours that apply are those where the recipient is.

Two implementation requirements follow. The sending platform needs to know the recipient’s time zone, which means deriving it from the number’s prefix rather than from the sender’s clock. And the window has to be enforced at the moment of scheduling rather than at the moment of sending, because a message queued at an acceptable hour and delivered at an unacceptable one is still a message delivered at an unacceptable hour.

Queues make this harder than it appears. Where a campaign is queued during the working day and drains overnight, the delivered times are spread across hours the sender never chose. The controls that prevent it are a window enforced at the queue entry as well as at the moment of send, and a queue depth that does not exceed what can be delivered inside the window. Where a large batch must go out, the schedule should be shaped rather than left to the rate the estate can sustain.

Records that demonstrate compliance

The record is the argument.

What has to be shown is which recipient was contacted, on which channel, at what time, under which permission, and with what outcome.

Five fields make that answerable: a case identifier, a recipient identifier, the message category, the delivery outcome with its timestamp, and the permission or suppression state that applied at the moment of sending. Recording the permission state at the time of sending is the detail most often missing, and it is the one that turns a dispute into a settled question: the record shows what the platform believed, and the preference history shows whether that belief was correct.

The record also has to survive the systems that produced it. Device logs are short-lived, the sending platform may be replaced, and the preference history may live in a CRM. Keeping an export of the relevant fields in storage the organisation controls is what makes the record retrievable years later, and record-keeping practice for operational logs is covered in NIST SP 800-92. Access-control objectives that structure who may see a collection record are organised in NIST SP 800-53 Rev. 5.

A workflow outline

The outline follows a reminder from the selection of recipients to the record that it was sent, with the controls that apply at each step. It is written around the enforcement points rather than the templates, because a rule that is not enforced by the platform depends on the person writing the message.

1. Record the recipient’s channel preference, acceptable hours and any suppression.
2. Enforce the preference and the cap at the point of sending, and log refusals.
3. Restrict content to the action and a reference, with no amount, account or reason.
4. Derive the recipient’s time zone from the number rather than from the sender’s clock.
5. Enforce the send window at queue entry as well as at the moment of send.
6. Define the escalation path with a terminal step, and record which step was taken.
7. Keep the case identifier, recipient, category, outcome and applied permission together.
8. Review the workflow against current rules for each market with the compliance owner.

Scope note: this article describes engineering data flows and workflow design, not legal advice. The rules that govern collection contact differ by market and change over time, and the thresholds and wording that apply to a deployment belong with the organisation’s compliance owner and its counsel.

One operational detail is worth settling early: what the platform does when a preference changes while a message is queued. A recipient who asks to be left alone at the moment a batch is being prepared should not receive the batch, and enforcing that requires the preference to be checked at the moment of sending as well as at the moment of scheduling. The check costs one lookup, it is the difference between a control that exists and one that mostly exists, and it is the kind of operational discipline described in the deployment guidance summarised on the about page.

Where the deployment operates in several markets, keep the preference and the cap per market as well as per recipient. The rules differ, and a recipient who is contacted in one market under one framework may be contacted in another under a different one; recording which framework applied to each message is what makes a later review answerable.