A spoken consent record must pin the script version that was read
The requirementstatement
Every consent record must carry the version and effective date of the consent script read to the consumer.
- Severityseverity
- HighHIGHRejected by at least one carrier or provider, and a common cause of failure at the rest.
- When it bitesphase
- Gates approvalapprovalGet this wrong and the brand or campaign is refused at registration.
- What is checkedobject
- campaign.message_flow + privacy policy
- Where it liveslayer
- OperationalOPERATIONAL
- How Ekas settles itdetectability
- AI · formAI_FORM
- A semantic question about what you wrote: whether a description matches a use case, whether a name looks like a filed entity. Judged by a model against written criteria.
- What the fix involvesfailureClass
- Fix the fieldRETRY_FIELD
- A better value in the form fixes it. Ekas can rewrite it and re-check.
- Who requires itauthorities
- FTCCTIApractice
- When it appliesapplicabilityText
- Applies when consent was collected by live verbal, IVR and point of sale.
Why this rule existsrationale
Scripts get improved, and every improvement makes the previous wording unprovable unless the record says which one was in force. This is the verbal twin of the capture-of-experience field, and it is the difference between "our script says X" — which a regulator reads as what you say today — and "this consumer heard version 3, effective 12 January". Brands miss it because the script lives in a document nobody versions.
How to fix itremediation
Version the consent script, give each version an effective date, and store the version identifier on every consent taken while it was live. Done when you can pick any past consent and reproduce the exact words that consumer heard.
A compliant exampleexample
Verbal opt-ins store script_version: 2026-03-a (effective 2026-03-01) with the agent ID and call UCID.
Common mistakespitfalls
- Attaching the current script to the registration proves what is read today. It is silent about the consents already taken, which are the ones a complaint will be about.
Notesnotes
Registration-side twin: we judge whether the programme describes storing the field, never whether the stored record exists.
Rules you will hit next
6 other rules read campaign.message_flow + privacy policy. Fixing one field to satisfy a single rule is how a resubmission trades one rejection for another, so read these before you change anything.
OPS-056Opt-out records must keep the words the consumer actually sentBlockingBLOCKINGOPS-085The programme must scrub deactivated numbers before sendingBlockingBLOCKINGOPS-210Telemarketing consent must retain the request, its purpose and the answerBlockingBLOCKINGOPS-236An IVR opt-in must log the prompt, the keypress, the time and the callBlockingBLOCKINGOPS-261Only the charity may use the numbers a charity collectsBlockingBLOCKINGOPS-199Consent records must capture all seven required fieldsHighHIGH
OPS-235 is one of 139 operational rules in the 915-rule 10DLC registry. Free to cite under CC BY 4.0.