AI Dialer documentation
How every call is checked before it is placed: the rules, the settings, and the evidence examiners can ask for.
How dial-time compliance works
Every attempt the AI Dialer places passes an eligibility check before the carrier is touched. Nothing is audited after the fact; a contact that fails any rule is never dialed, and the reason is written to the record.
Traditional dialers pace to a human being free and check compliance when the QA team samples recordings a week later. The Domu AI Dialer runs the checks in the other order. Before any call is scheduled, dialed, or any account detail is read to the agent, the request goes to a policy engine that answers one question: is this allowed, right now, for this person? A yes carries a record of every rule it passed. A no carries the name of the rule that stopped it. A question the engine cannot answer safely is treated as a no.
The order of evaluation is fixed and the same for every channel. Each stage can block on its own; the first block wins and is recorded, so a report can tell you exactly which rule stopped a given attempt.
Eligibility pipeline
Checks run in this order on every attempt. The first block wins and is recorded.
How Domu enforces it
- Three decisions go through the engine: may we schedule this call, may we dial it now, and may the agent be told this piece of information.
- Compliance rules can only block. Client settings can only make a program stricter than the rules; nothing a client configures can loosen a regulatory stop.
- Every decision is stamped with the version of the rule set that made it, so an attempt from last quarter can be re-read against the rules that applied that day.
What examiners test
The OCC's interagency FDCPA procedures tell examiners to review call logs, call recordings, scripts and complaint files and to determine whether the institution communicated in any prohibited manner. Every page in these docs ends with the evidence the AI Dialer produces for that review.
Evidence produced
Eligibility record per attempt (rule set version, every check passed or the block reason), kept for every attempt and provided to the client on request.
How the policy engine decides
Compliance is not a list of if-statements inside the dialer. It is a separate rule set, written in a small formally verified policy language, built so that rules can be layered (federal, state, city, client) without breaking each other. Prohibitions always beat permissions.
The engine exists to define rules in a way that stays correct no matter how many are stacked on top of each other. Federal collection and telemarketing rules are already represented, along with a growing set of more granular state and local ones. It is built on Cedar, an open-source authorization language created at AWS and proven correct against a mathematical model, chosen for one property above all: a forbid rule overrides every permit rule, by proof rather than by convention. Domu writes regulatory limits as forbids and business logic as permits, so no campaign setting, client preference, or later feature can widen a legal stop.
The language is deliberately small. It has no loops, no recursion and no custom functions, which keeps every decision to one bounded pass and lets the whole rule set be analyzed automatically for questions like "can any request ever reach this data". The limits that smallness imposes are handled outside the engine and checked again inside it.
The engine answers questions; it does not hold facts. Facts about the person come from the Subject Data Platform (SDP), which answers one question for every consumer on a list: what do we know about this person? The name is deliberate: a customer data platform describes a company's customers, and the people Domu calls are not Domu's customers. The SDP holds contact details, jurisdiction, consent status, and the protective flags (deceased, bankruptcy, active-duty military, cease request, attorney represented, do not call, dispute). The engine reads it at decision time, with each fact's source and age. When a rule needs a fact about the person that is not yet tracked, the SDP is where it gets added, and the rule set does not change.
Eligibility pipeline
Checks run in this order on every attempt. The first block wins and is recorded.
Settings
| Setting | Options | Default | Enforces |
|---|---|---|---|
| Decision outcomes | Allow / Deny / Not evaluable | System | Fail closed |
| Rule precedence | Forbid always overrides permit | Fixed | Regulatory stops cannot be widened |
| Protective flags | Deceased, bankruptcy, active-duty military (SCRA), cease request, attorney represented, do not call, dispute | Presumed clear from the client's screening at delivery unless the client feeds a value | Reg F 1006.6; SCRA; client policy |
| Flag source | Client feed, consumer statement on a call, vendor scrub, or presumed from client screening | Presumed from client screening | Evidence provenance |
| Jurisdiction levels | Country → state → county → city; every level that applies is checked and the tightest wins | Resolved per contact | Federal, state and municipal rules at once |
| Unresolved jurisdiction | Deny when the location cannot be resolved with confidence | Deny | Fail closed |
| Evidence freshness | Maximum age for compliance flags and attempt counts | 24 h for flags; 15 min for attempt counts | Stale data is not evidence |
| Rule-set version | Hash of the exact rule text, stamped on every decision | Automatic | Auditability |
| Client overrides | Tighten only | None | Client policy |
How Domu enforces it
- Hard stops are separate rules, one per condition (bankruptcy, deceased, cease request, attorney represented, do not call, litigation, consumer dispute), so a missing fact about one can never hide a stop on another, and the audit log names the exact rule.
- "Not evaluable" is kept apart from "deny" on purpose. A rule deny is a compliance event; a not-evaluable result is a data problem (a missing field, a stale count, an unknown jurisdiction). Both stop the call, but they are reported in different places so neither hides the other.
- Clients screen their own files before placement, so by default the protective flags are presumed clear on the client's responsibility, and that presumption is recorded as such. A client that sends a live feed of these flags (a bankruptcy notice, a deceased match, a military status check) replaces the presumption with a confirmed value and the decision gets more current and more accurate. Either way, the decision record shows which it was.
- Every compliance flag carries where it came from (the client's file, the consumer's own statement, a vendor) and when it was last confirmed. A flag that is only presumed, for example "not bankrupt because the client's screening said so at delivery", expires on its own schedule and blocks the call once it is stale.
- The engine checks its own inputs. If the calendar day used to look up a calling window does not match the consumer's local day, or a window for the wrong state is supplied, the decision is a deny, so a software bug upstream becomes a blocked call rather than a wrong one.
- The same rules run unchanged for non-US programs; a Colombian contact resolves to country, departamento and municipio and is checked the same way.
- The core decision is call or no-call, and it is the one a bank's compliance review is built around. The same engine is being extended to finer-grained decisions during the call, starting with what the agent may be told; see Agent disclosure.
What examiners test
Examiners assess the compliance management system before they test transactions. A rule set that can be read without reading code, that names the rule behind every block, and that fails closed on missing data is the system they are assessing.
Evidence produced
Readable rule set with citations, rule-set version per decision, and a per-decision record of outcome, deciding rule and the evidence consulted.
Do Not Contact
Suppression lists are the first gate. A number or account on any active suppression list is blocked across voice, SMS and email, and the block is recorded with the list that caused it.
Domu keeps four suppression sources and evaluates all of them on every attempt: the client's corporate DNC, the national Do Not Call registry, a litigation and attorney-represented list, and consumer requests captured during a conversation. Lists can be uploaded as files, synced from the client's system of record, or written by the AI agent in real time when a consumer asks not to be contacted.
These flags live in the Subject Data Platform, not inside the dialer, so the same answer is given to the scheduler, the dialer and the agent. Clients can send them as a file, through the API, or as a live feed; a live feed is what makes the record current rather than presumed.
Settings
| Setting | Options | Default | Enforces |
|---|---|---|---|
| Corporate DNC | File upload, API, or CRM sync; by phone number or account ID | On | Client policy; TCPA internal DNC |
| National DNC scrub | On / Off per campaign | On for any campaign with a marketing purpose | TCPA, 47 CFR 64.1200 |
| Litigation and attorney list | Upload or sync; matches on number, account, or name + zip | On | Reg F 1006.6(b)(2) |
| Active-duty military | Flag from the client file or a vendor SCRA check | Presumed clear unless supplied | SCRA; client policy |
| Bankruptcy, deceased, cease | Flags from the client file or set by the agent | On | Reg F 1006.6(c); client policy |
| Duration | Permanent, or start and end date | Permanent | Internal DNC kept at least 5 years |
| Scope | All campaigns, one campaign, or a category of campaigns | All campaigns | Client policy |
| Agent-captured requests | Applied immediately as a global block | On | Reg F 1006.6(c); TCPA revocation |
How Domu enforces it
- A consumer who says "stop calling me" mid-call is added to the suppression list before the call ends; no later attempt on any channel is placed.
- Blocked contacts carry a block reason code and the name of the list that matched, so a report can show how many attempts each list stopped.
- Quick search lets a compliance user look up any number and see every list it sits on, with start and end dates.
- Each suppression flag records its source and the date it was confirmed. A flag confirmed by the consumer or the client's feed holds indefinitely; a flag merely presumed from the client's screening at delivery expires after a configurable period (one delivery day by default) and the account is held until it is refreshed.
What examiners test
Examiners test whether internal do-not-call requests were recorded and honored for at least five years and whether cease requests stopped all further attempts. They will ask for the request, the timestamp, and the next attempt on that account.
Evidence produced
Suppression log (number, list, source, timestamp, who or what added it) and the per-list blocked-attempt count for any period.
Consent and revocation
Each number carries a consent status per channel. Numbers without consent are never autodialed; they can only be reached by a human-initiated attempt, and revocation by any reasonable means is honored at once.
The dialer treats consent as data on the contact, not a campaign setting. A number can be consented for voice and not for SMS, or consented for servicing calls and not for marketing. The client supplies the status at upload or through the CRM sync, and the AI agent updates it when a consumer gives or withdraws consent on a call.
Settings
| Setting | Options | Default | Enforces |
|---|---|---|---|
| Consent status | Consent / No consent / Revoked, per number and channel | Taken from the client file | TCPA prior express consent |
| No-consent routing | Block, or route to a human-initiated (click-to-dial) queue | Block | TCPA; state mini-TCPA laws |
| Revocation capture | Oral, text reply, email, written; applied immediately | On | TCPA revocation by any reasonable means |
| Proof of consent | Stored with source, date, channel and wording | On | OCC TCPA exam procedures |
| Reassigned Numbers Database | Query before first attempt and every 30 days | On | FCC RND safe harbor |
| Marketing purpose | Servicing / Marketing per campaign | Servicing | Written consent required for marketing |
How Domu enforces it
- The RND safe harbor covers only database errors. Domu also runs a name-to-number match on new numbers and flags mismatches for human review rather than autodialing them.
- Revocations are mirrored back to the client's system of record so the next file upload does not reinstate a withdrawn consent.
What examiners test
The revised OCC TCPA procedures (Bulletin 2023-35) direct examiners to review consent and opt-out databases, revocation protocols, and whether automated communications stopped after revocation. They assume consent can be revoked orally.
Evidence produced
Consent record per number (status, source, date, wording), revocation log with time to enforcement, and RND query log.
Calling windows and time zones
The dialer resolves a time zone for every number, not every account, and only dials inside the window where every rule that applies to the consumer overlaps.
A consumer with a Texas zip code and an Arizona cell number has two possible time zones. Domu computes the window that satisfies both and dials only inside it. If a zone cannot be resolved with confidence the number is held, not dialed.
Rules are layered by place. A contact in a city with its own collection ordinance is bound by the city window, the state window and the federal window at the same time, and the tightest decides. Adding a municipality is adding data, not changing logic. The engine refuses a decision when a level that applies is missing or when the stack skips a level, because resolving less precisely is a way of loosening.
Settings
| Setting | Options | Default | Enforces |
|---|---|---|---|
| Zone resolution | Zip code → area code → state → campaign default, with confidence scoring | Zip, then area code | Reg F 1006.6(b)(1) |
| Multiple numbers | Window = intersection of all zones on the account | On | Reg F; state law |
| Unresolved zone | Hold / Use campaign default | Hold | Reg F presumption of inconvenience |
| Default window | Start and end, consumer local time | 8:00 a.m. to 9:00 p.m. | Reg F 1006.6(b)(1)(i) |
| State windows | Per state, narrower than default | Loaded from the state rule library | State collection statutes |
| Holidays | Federal, per state, client-defined | Federal + state | State law; client policy |
| Customer preferred time | Up to three day-and-time slots per contact, in the consumer's zone | Off unless supplied | Reg F consumer-designated time |
| Inconvenient time or place | Flag set by agent from the consumer's words or circumstances; blocks that time, place, or workplace | On | Reg F 1006.6(b)(1) |
| Workplace numbers | Tag at upload; blocked if employer prohibits | Honor tag | Reg F 1006.6(b)(3) |
How Domu enforces it
- Preferred-time slots take priority over the default window: a consumer who asked for Tuesdays after 6 p.m. is only attempted then, and a second slot is used only if the first produces no contact.
- "Inconvenient" does not have to be said. If the consumer describes a shift, a hospital stay, or asks not to be called at work, the agent records the circumstance and the window narrows.
- Every window decision is computed at dial time against the current clock in the consumer's zone, including daylight-saving changes.
- Consumer-requested hours are honored as a narrow exception: only at the federal and state level where the statute allows it, only inside the hours the consumer actually asked for, with a recorded consent timestamp, and never past a hard stop or an attempt cap.
- Where the area code and the address point to different time zones, the dialer applies the more restrictive of the two.
What examiners test
Examiners presume that attempts between 9:00 p.m. and 8:00 a.m. in the consumer's time zone are inconvenient and look for attempts at a time or place the consumer said was inconvenient, or at a workplace known to prohibit calls.
Evidence produced
Per-attempt record of the resolved zone, the window applied, and the rule that set it; list of held numbers with the reason.
State rule library
State collection and telemarketing laws are maintained as a versioned rule library. When a state is more protective than federal law, the state rule wins.
Each state entry holds its calling window, attempt caps, holiday list, required disclosures and any consent or licensing conditions. Domu maintains the library, reviews it with outside counsel, and publishes a change log the client can subscribe to. Clients can tighten any rule for their own program; they cannot loosen one below the library value.
Settings
| Setting | Options | Default | Enforces |
|---|---|---|---|
| State attribution | By zip code, area code, or both with a priority order when they disagree | Zip, then area code; stricter state wins on conflict | State law |
| Rule priority | Federal floor, state override, client tightening | Strictest applicable | Reg F 1006.104 |
| Mini-TCPA states | Autodial blocked without written consent | On | FL, OK, WA and others |
| Library version | Pinned per campaign, auto-advance on | Auto-advance with notice | Change management |
| Client overrides | Tighten only | None | Client policy |
How Domu enforces it
- Every rule in the library cites its source statute and the date it was last reviewed.
- When a state changes its law, the client's compliance contact receives the diff before the new version goes live.
What examiners test
The FDCPA procedures note that state law more protective of the consumer is not preempted. Examiners expect the institution to know which state rules apply and to show that the dialer applied them.
Evidence produced
Rule library export with citations and review dates; change log; per-attempt record naming the state rule applied.
Attempt frequency
Attempts are counted per debt, across every channel and every system that dials on the client's behalf, so the 7-in-7 presumption and the post-conversation cooling period are enforced on the whole book.
Regulation F presumes a violation when a collector places more than seven calls about a particular debt in seven days, or calls within seven days of a telephone conversation about that debt. The counter has to be shared: if the client's human agents or a second dialer also call, those attempts count too. Domu exposes an attempt-log API so other systems can write their attempts in and read the running count out before dialing.
Regulation F frames the seven-call limit and the seven-day cooling period as presumptions a collector may rebut. Domu does not automate the rebuttal and does not try to. Both are implemented as hard stops: a system that decides for itself that a presumption has been overcome is a system that dials past the limit. This is Domu's rule and is stricter than the regulation on purpose.
Settings
| Setting | Options | Default | Enforces |
|---|---|---|---|
| Rolling cap | N attempts per rolling window; window in days, hours or minutes | 7 in 7 days per debt | Reg F 1006.14(b)(2) |
| Post-conversation cooling | Days after a live conversation before the next attempt | 7 days | Reg F 1006.14(b)(2)(ii) |
| What counts | Connected and ringing attempts; busy and not-in-service excluded | Reg F definition | Reg F comment 14(b)(3)(ii)-1 |
| Counting unit | Per debt; student loans aggregated by account number | Per debt | Reg F 1006.14(b)(5) |
| Daily cap | Attempts per account per day | 1 | State law; client policy |
| Global cap | Attempts per account per campaign lifetime | Client policy | Client policy |
| State caps | Loaded from the state rule library | On | e.g. MA, NY, WA |
| Shared counter | Attempt-log API for other dialers and manual calls | On | Reg F counts all collector attempts |
| Consent exception | Attempts the consumer asked for in the last 7 days are excluded | On | Reg F 1006.14(b)(3)(i) |
How Domu enforces it
- Counting is defined precisely and checked before any count is trusted: a call that connected counts whether or not anyone spoke, an unanswered ring counts, a voicemail counts; a busy signal or a number not in service does not. Calls the consumer asked for in the last seven days and calls to the consumer's attorney, the creditor, or a credit bureau are excluded.
- The cooling period is counted in the consumer's local calendar days, with the day of the conversation as day zero, so the boundary does not move with the hour a call happened to be placed.
- A text message is not a telephone call and is never counted as one; the frequency rules apply only to calls and voicemails. Message limits are separate.
- Caps can be set per category of campaign, so early-stage and late-stage programs can run different retry strategies under the same federal ceiling.
- A blocked attempt because of frequency is recorded as such, with the count that triggered it, so no retry is silently dropped.
- An attempt count that is older than fifteen minutes, or a history that was never computed, is not treated as a clean slate: the request is not evaluable and the call is held.
What examiners test
Examiners look at call logs for more than seven attempts in seven days on a debt, and for any attempt inside seven days of a conversation. They test the institution's and its vendors' logs together.
Evidence produced
Attempt log per debt with channel, outcome and whether it counted; frequency-block report; API access log for external attempts.
Pacing and abandonment
The dialer is paced to carrier capacity and to a hard abandonment ceiling, not to agent headcount. Because an AI agent answers every connected call, abandonment stays near zero, and the ceiling exists so that it cannot drift.
Pacing is machine-driven: roughly 3,000 attempts a minute at steady state, higher at peak. The rate is reduced automatically when the abandonment ceiling, the inbound queue threshold, or a carrier limit is approached. For programs that still route some calls to human agents, the classic lines-per-agent controls are available on that queue.
Settings
| Setting | Options | Default | Enforces |
|---|---|---|---|
| Pacing mode | Machine (AI agent answers), Progressive, Preview (human queue) | Machine | Program design |
| Abandonment ceiling | 0 to 3% per campaign per 30 days | 3% | TCPA safe harbor, 47 CFR 64.1200(a)(7) |
| Abandoned call definition | Live answer not connected to an agent within 2 seconds of the greeting | 2 seconds | TCPA |
| Auto-pause | Pause delivery when the rolling abandonment rate exceeds the ceiling | On | TCPA; client policy |
| Ring time | Seconds or rings before giving up | 15 seconds / 4 rings | TCPA 47 CFR 64.1200(a)(6) |
| Lines per agent | Human queue only; initial and maximum | 1.5 / 3 | Abandonment ceiling |
| Inbound throttling | Reduce outbound when inbound queue or longest wait exceeds a threshold | On | CX policy |
| Carrier capacity | Concurrent channels per carrier trunk | Contracted capacity | Carrier terms |
How Domu enforces it
- An abandoned call that does happen plays the identification message required by the TCPA within two seconds and offers an opt-out.
- Abandonment is computed on live answers only; answering machines and unanswered attempts are excluded from the denominator, as the rule requires.
What examiners test
Examiners check that abandoned calls are measured per campaign over 30 days against the 3% safe harbor, that the ring time rule is met, and that abandoned calls carried the required message.
Evidence produced
Daily abandonment rate per campaign with the 30-day rolling figure, auto-pause events, and the abandoned-call message log.
Answering machines and voicemail
Answering-machine detection decides within the first seconds whether a person or a machine answered. Machines get a limited-content message or nothing; people get an agent with no dead air.
Dead air is the most common complaint about automated dialers and a signal examiners read as abandonment. Domu's agent begins speaking as soon as a live voice is detected, and the detection timers are bounded so a consumer never waits in silence.
Settings
| Setting | Options | Default | Enforces |
|---|---|---|---|
| Answering-machine action | Hang up / Leave limited-content message / Leave client-approved message | Leave limited-content message | Reg F 1006.2(j) |
| Limited-content template | Locked template: consumer name, request to call back, callback number, name of the person to ask for, optional hours | Reg F template | Reg F 1006.2(j) |
| Voicemail counts toward frequency | Always on | On | Reg F: an attempt is an attempt |
| Live-voice timeout | Milliseconds before the agent speaks without a classification | 1,800 ms | No dead air |
| Silent-call detection | Mark and end calls with no voice from either side | On | Abandonment accounting |
| AMD false-positive review | Sample of machine-classified calls reviewed weekly | On, 2% sample | CX quality |
How Domu enforces it
- The limited-content template cannot be edited into a communication: it never states the debt, the amount, or the creditor. Anything beyond the template is a communication and triggers validation and disclosure rules.
- A message left for the wrong person is still treated as a third-party contact risk, so the template uses only the consumer's name.
What examiners test
The FDCPA procedures define the limited-content message precisely. Examiners listen to voicemail recordings to confirm the message matches 12 CFR 1006.2(j) and count voicemails toward call frequency.
Evidence produced
Recording and transcript of every voicemail left; template version in effect; AMD classification and timer values per call.
Caller ID and identity disclosure
Every attempt presents a working, branded caller ID in the consumer's area, and every connected call opens with a meaningful disclosure of who is calling and why.
Geodynamic dialing matches the outbound number to the consumer's area code to lift pickup, but the number is always one the client owns, answers, and has registered with the carriers. Number reputation is monitored so a flagged number is rotated out before it is labeled spam.
Settings
| Setting | Options | Default | Enforces |
|---|---|---|---|
| Caller ID per campaign | Fixed number, or geodynamic pool | Geodynamic pool | TCPA caller ID; Truth in Caller ID Act |
| Number ownership | Client-owned numbers only; all answer inbound | Required | TCPA 47 CFR 64.1601 |
| Branded caller ID | Client name and logo registered with carriers | On | CX policy |
| Reputation monitoring | Spam-label checks, warm-up, rotation thresholds | On | Deliverability |
| Identity disclosure | Agent states its name, the client, and that the call concerns an account, before any account detail | On, locked script line | Reg F 1006.14(b)(2)(vi), 1006.18(e) |
| Right-party verification | Verify identity before disclosing any account information | On | Reg F third-party disclosure |
| AI disclosure | State that the caller is an automated assistant | On | State AI-disclosure laws; client policy |
How Domu enforces it
- Disclosure lines are locked in the agent's script and versioned; a change requires approval through the agent change workflow and is logged.
- If verification fails, the agent ends the call with a limited-content message and no account detail is shared.
What examiners test
Examiners check that calls meaningfully disclose the collector's identity and that no false or misleading representation of the debt is made. Scripts and recordings are the test material.
Evidence produced
Script version per call, disclosure confirmation flag per call, caller ID used per attempt, and reputation monitoring history per number.
What the agent may be told
Account details are revealed to the AI agent step by step, only as identity checks are passed. Today those rules live in the agent's instructions; moving them behind the policy engine, which is rolling out now, means there is no way to talk the agent into leaking information other than asserting identity facts that are wholly false.
Disclosure rules are written against the piece of information, not the tool that fetches it. The exact balance, the creditor name or the account number has one rule each, whatever path the data would take to reach the agent. That keeps the rule true when a new tool or prompt is added.
At the start of a call nothing has been verified, so only low-sensitivity facts (the consumer's first name, the callback number) are available to the agent. Everything else is fetched mid-call through a gated request that passes only once the required identity factors have been confirmed.
Verification is proportionate. Domu checks the identity factors the client requires (date of birth, last four digits of an identifier, zip code) against the record, and a caller who gets them wrong is not told anything. There is a reasonable limit to what a collector is expected to verify proactively; a caller who correctly asserts every required fact is treated as the right party, which is the same standard a human agent is held to.
Settings
| Setting | Options | Default | Enforces |
|---|---|---|---|
| Field sensitivity | Low / Medium / High per field | Domu catalogue, client can raise | Reg F third-party disclosure |
| Pre-call loading | Low-sensitivity fields only | Fixed | No disclosure before verification |
| Identity factors | Factors required per sensitivity level (e.g. date of birth, last four of account, zip) | Client policy within Domu minimums | Right-party verification |
| Third-party disclosure | Allowed only for a basis the FDCPA names: the consumer's attorney, the creditor, either side's attorney, prior consent given directly to Domu, court permission, a credit bureau where otherwise lawful | Deny unless a recorded basis exists | FDCPA §1692c(b) |
| Deceased consumers | No account disclosure on any call | On | Reg F 1006.6(a) |
| Disclosure log | Field, basis, verification level and time recorded per disclosure | On | Auditability |
How Domu enforces it
- Rollout status: disclosure rules are enforced in the agent's instructions today and are being gated behind the policy engine. Once gated, a prompt-injection attempt or a clever conversational path cannot reach a field the engine has not released.
- A third-party basis is a recorded fact from an authorization record, never an argument the agent can supply itself. An unrecognised or misspelled basis simply fails: it is denied, not guessed at.
- If verification fails, the agent ends the call with a limited-content message and no account detail is shared.
- Because prohibitions override permissions, adding a new tool or prompt cannot create a new path to a sensitive field; the field rule still applies.
What examiners test
Examiners look for communication of debt information to anyone other than the consumer, and for false or misleading statements about the debt. The disclosure log answers both: what was said, to whom, on what basis, after which verification.
Evidence produced
Per-call disclosure log and the field sensitivity catalogue in effect for the client.
Channels and opt-out
Voice, SMS and email are governed separately. A consumer can refuse one medium without refusing all of them, and every electronic message carries a clear opt-out.
Suppression, consent and frequency are all tracked per channel. A "don't text me" is a medium restriction, not a cease request, so voice can continue; a cease request stops every channel. The agent is trained to tell the two apart and to confirm which one the consumer means.
Settings
| Setting | Options | Default | Enforces |
|---|---|---|---|
| Channel eligibility | Voice / SMS / Email per contact | From the client file | Reg F 1006.6, 1006.14(h) |
| Medium restriction | Block one channel on the consumer's request | On | Reg F 1006.14(h) |
| Cease request | Block all channels; one closing notice permitted | On | Reg F 1006.6(c) |
| Electronic opt-out notice | Required text in every SMS and email | On, locked | Reg F 1006.6(e) |
| Opt-out handling | STOP keywords, reply, link; applied immediately | On | Reg F; TCPA |
| Third-party protection | Send only to addresses the consumer used or consented to; bona fide error procedures documented | On | Reg F 1006.6(d) |
| Cross-channel frequency | Voice attempts and messages counted on the same debt record | On | Reg F |
How Domu enforces it
- Opt-out notices are versioned text; the message body cannot be sent without one.
- Email and SMS to a third party are a presumed violation unless the address came from the consumer, so new addresses are never guessed or appended from data vendors.
What examiners test
Examiners check that electronic communications carried an opt-out notice, that opt-outs and medium restrictions were honored, and that no messages reached third parties.
Evidence produced
Message log with notice version, opt-out log with time to enforcement, and the medium-restriction flags per consumer.
Contact lists and expiry
Lists are the source of truth for who is eligible. Uploads are deduplicated, scrubbed at load, time-boxed, and every record carries a status that explains why it is or is not dialable.
A list can be uploaded as a file, pushed through the API, or synced on a schedule from the client's system. Targeting (who is called first) is kept separate from eligibility (who may be called at all), so a priority change can never override a compliance block.
Settings
| Setting | Options | Default | Enforces |
|---|---|---|---|
| Load mode | Append / Replace / Update fields | Append | Data hygiene |
| Deduplication | By account, by number, or by client-chosen fields | Account + number | Frequency accuracy |
| Scrub at load | All suppression lists, consent, litigation, RND | On | See Do Not Contact and Consent |
| Validity window | Start date and time-to-live per list | 30 days | Client placement terms |
| Expiry | Earliest of list TTL, placement end, state limitation, client recall | Earliest wins | Reg F 1006.26 time-barred debt |
| Priority and lead score | Client-supplied ordering fields | Optional | Targeting only |
| Status codes | Open, delivered, contacted, blocked (with reason), expired, closed | System | Auditability |
How Domu enforces it
- Rejected rows come back as a file with the reason per row so the client can fix the source, not just the upload.
- Expired records are never dialed even if a later list includes them; a fresh placement with a new start date is required.
What examiners test
Examiners look for collection attempts on time-barred or recalled debt and for records that were contacted after the placement ended.
Evidence produced
List manifest (source, load time, rows accepted and rejected with reasons), status history per record, and expiry report.
Recording, audit and retention
Every call is recorded and transcribed, every setting change is logged, and everything is kept for at least three years after the last collection activity on the debt.
Compliance evidence is produced as a side effect of dialing, not assembled later. Recordings, transcripts, eligibility records, outcome codes and payment events share one call ID, so a single query answers an examiner's question about any attempt.
Settings
| Setting | Options | Default | Enforces |
|---|---|---|---|
| Call recording | All calls; two-party consent notice where required | On | Reg F 1006.100; state recording law |
| Retention | Years after last collection activity | 3 years, or client policy if longer | Reg F 1006.100 |
| Data residency | Region per client; no data retained in Domu's SaaS beyond the contracted scope | Client contract | Client data policy |
| PII masking | Mask account numbers and payment data in transcripts and UI by role | On | GLBA; client policy |
| Role-based access | SSO, roles per client, per-campaign scoping | On | SOC 2 Type 2 |
| Change log | Every rule, list, script and setting change with actor and approval | On | Change management |
| Kill switch | Pause a campaign, a channel, or all dialing for a client | Available to client admins | Operational risk |
| Block-reason reporting | Rule name, group and reason on every blocked attempt | On | Auditability |
| Exports | Call trace, eligibility log, attempt log, complaint log; provided to the client on request | On | Exam readiness |
How Domu enforces it
- A model or prompt change to the AI agent is a change-logged event with a version number, visible to the client before it goes live.
- The call trace export reproduces the full decision path for one attempt: list, rules evaluated, result, caller ID, recording link, outcome.
What examiners test
Record retention is an explicit FDCPA exam procedure: records from the start of collection activity until three years after the last activity, and call recordings for three years from the call. Examiners sample call logs and recordings directly.
Evidence produced
Retention policy in effect, sample call trace for any attempt, and the access and change logs for the exam period.
Complaints and vendor oversight
A bank is liable for what its vendor does on the phone. Domu is built to be examined as that vendor: complaints are tagged to calls, monitoring is continuous, and the evidence pack is standing, not assembled on request.
The OCC's procedures tell examiners to review the institution's policies for monitoring third parties, its training, its audit findings and management's responses, and then to test transactions: call logs, scripts and recordings. Domu produces each of those as a routine output.
Settings
| Setting | Options | Default | Enforces |
|---|---|---|---|
| Complaint capture | Agent-tagged on call, client-submitted, carrier or regulator referral | On | Complaint management |
| Complaint linkage | Each complaint tied to the call, the recording, and the rules in effect | On | Exam testing |
| QA scoring | 100% of calls scored on disclosure, tone, accuracy, and prohibited conduct | On | Reg F 1006.14, 1006.18 |
| Critical auto-fail | Immediate escalation on a prohibited statement or missed disclosure | On | Client policy |
| Audit reports | Monthly compliance summary; findings with owner, due date, resolution | On | Third-party risk management |
| Evidence pack | SOC 2 Type 2, penetration test, rule library, sample call traces, retention policy | Available on request | TPRM onboarding |
| Training records | Agent script training and human reviewer training with dates | On | Exam procedures |
How Domu enforces it
- Open findings are visible on the client dashboard with owner and due date; nothing closes without a documented resolution.
- Every complaint report includes what the consumer said, what the agent said, and which rule applied, in one view.
What examiners test
Both OCC procedure sets end the same way: assess the compliance management system, then test transactions. A vendor that can hand over logs, scripts, recordings and complaint files by call ID shortens that test.
Evidence produced
Complaint log with call linkage, QA scores and auto-fail events, monthly compliance summary, and the standing evidence pack.
How rules are tested and rolled out
Every rule in the set is deliberately broken in a test suite to prove that a test would catch it, every calling window is swept at its boundary minutes, and a new rule runs in shadow against live traffic before it blocks a single call.
A compliance rule that nothing can break is decoration. Domu's suite mutates each rule in turn (deletes it, loosens a threshold, flips a boundary, injects the broadest possible permission) and requires that a named test fails. The suite also tests in the other direction, because an over-restrictive rule produces no incident and no complaint: tightening a window by one minute must also break a test.
Boundaries are checked by table, not by sample. Every jurisdiction's opening and closing minute, on every weekday, is evaluated on both sides of the line, because a "greater than" where the rule needs "greater than or equal" allows a call at exactly 9:00 p.m. and no spot check would find it.
Settings
| Setting | Options | Default | Enforces |
|---|---|---|---|
| Rule change review | Compliance approval, then version bump; approval status recorded per data set | Required | Change management |
| Rollout stages | Retrospective (score past traffic) → Shadow (evaluate live, do not enforce, count outcomes per rule) → Enforce, one rule group at a time | All three | No all-or-nothing switch |
| Shadow outcomes | Allow / Deny / Not evaluable, counted per rule | On in shadow | Know what would block before it blocks |
| Client notice | Diff of rule changes sent to the client compliance contact before enforcement | On | Vendor oversight |
| Jurisdiction data status | Verified / Unverified per jurisdiction; unverified rows cannot be enforced in production | Gated | Production data gate |
How Domu enforces it
- Mutation testing has already found rules that could be deleted without any test failing, and fixed them; that is the point of running it, and the results are kept.
- Publishing a rule-set version is not approval of its legal content. Legal review and the production-data gate are separate steps with separate owners.
- Rule-set changes are visible on the client dashboard with the version hash, the reviewer and the date.
What examiners test
Examiners review audit and monitoring findings and management's responses. A rule set with a test record, a shadow period and a version history is that audit trail, generated as part of engineering rather than assembled for the exam.
Evidence produced
Test and mutation results per rule-set version, shadow-period counts per rule, and the rollout log with approvals.
We’re building the next generation of engagement technology: intelligent, automated and compliant. Our mission is to empower financial institutions to orchestrate every stage of the servicing lifecycle with dignity and unprecedented efficiency.
Supported by
