Published 2026-09-19 · LuckyMDM Blog
Whether a collection record proves anything does not depend on how many rows you have stored. It depends on whether the time field in each row can be resolved to the minute, and whether you can show that the value has not been touched since it was written. A collection log that says only 2026-09-19 — no seconds, no time zone, no origin code — can prove that you contacted the person. It cannot prove when. And almost every dispute that actually reaches a regulator or a court turns on when, not whether: was the contact inside the permitted window, and did the number of attempts stay inside the weekly cap.
A common assumption in operations teams is that a timestamp is a by-product of writing a record, and therefore travels with the data. It does not. A timestamp is supplied by a clock at the moment of writing, which means the value inherits three external properties: whose clock it was, how fine the granularity was, and whether it can be changed afterwards. If any one of the three fails, the record proves that something happened but not when it happened.
Device leasing and device subscription operators are unusually exposed to this, because the compliance rules that govern collection contact are time-of-day and frequency rules, not volume rules. Under the Fair Debt Collection Practices Act, 15 U.S.C. 1692c(a)(1), and its Regulation F implementation at 12 CFR 1006.6(d)(1), a debt collector must assume that the convenient times for communication are after 8:00 a.m. and before 9:00 p.m. local time at the person's location, absent knowledge of circumstances to the contrary. Under 12 CFR 1006.14(b)(1), a debt collector must not place a telephone call more than seven times within a period of seven consecutive days, and must not call again within seven consecutive days after having had a telephone conversation with that person. Both of those tests are decided on clock readings, not on the existence of a record.
The same collection action is stamped in three places: the clock on the subscriber's handset, the gateway receipt at the messaging or push provider, and the server clock of the operator's own system when the row is inserted. These three values are rarely identical. The gap may be seconds, or it may be a day.
The reason this matters is that a device clock is user-settable. Both iOS and Android allow the user to turn off automatic date and time and set the clock manually; once that is done, every timestamp the device reports is offset. A record whose only time value came from the subscriber's device carries almost no weight in a dispute, because the opposing party only has to raise the possibility of an incorrect device clock to push the burden back onto the operator.
Granularity is the resolution of the value: day, minute, or millisecond. The coarser it is, the less it can be placed inside a compliance window.
Here is the arithmetic. The prohibited period runs from 9:00 p.m. to 8:00 a.m., which is 11 hours; the permitted period is the remaining 13 hours of the 24-hour day. If the record is day-only, the share of the day in which that contact could have fallen inside the prohibited window is 11 divided by 24, or roughly 45.8 per cent. Nearly half of the clock is unaccounted for. Add minutes — say 14:32 — and the placement is determined; there is nothing left to interpret.
Immutability is the deepest of the three. Even with an authoritative clock and millisecond precision, the value loses force if the row can be edited afterwards without a trace.
The underlying principle is that authenticity review looks at the system, not just the artifact. Under the Federal Rules of Evidence, a business record is admissible under FRE 803(6) only if the opponent or a qualified witness establishes that it was made at or near the time by someone with knowledge, kept in the course of a regularly conducted activity, and that making it was a regular practice — and FRE 902(11) lets an operator self-authenticate that record only with a written custodian certification made under penalty of perjury. FRE 901(b)(9) separately allows authentication by evidence describing a process or system and showing that it produces an accurate result. All three ask what the system does, not what the row contains. If an operations user can run an UPDATE against a collection row and no append-only trail records it, the immutability property is zero.
| Time field | Who generates it | Typical granularity | Can one party alter it | Evidentiary weight |
|---|---|---|---|---|
| Device local time | The subscriber's handset | Seconds | Yes — turn off automatic date and time | Weak; corroborating only |
| Gateway receipt time | Messaging or push provider | Seconds, sometimes milliseconds | No — third party holds it | Moderate to strong, if the receipt is retained |
| Server insert time | The operator's own database | Milliseconds | Possibly, depending on permissions and log design | Strong, provided the log is append-only |
| Third-party time stamp | A time-stamp authority | Seconds | No | Strongest; can stand on its own |
The most common misreading of this table is to treat server insert time as automatically strongest. It is not. It is strong only if the operator can show nobody edited it. Because the operator holds its own database permissions, a timestamp that cannot be shown to be append-only looks to the other side very much like a spreadsheet that can be edited.
For operators who want an external anchor, the Internet Engineering Task Force published the Time-Stamp Protocol in RFC 3161 and the accompanying policy requirements for time-stamping authorities in RFC 3628. On the control side, NIST Special Publication 800-53 Revision 5 includes AU-8 (Time Stamps), which requires internal system clocks to generate time stamps for audit records, and AU-8(1), which requires synchronisation with an authoritative time source. Together these describe the two properties that matter: timestamps come from system clocks, and those clocks are synchronised.
Three provisions in Regulation F (12 CFR Part 1006) do most of the work. First, 12 CFR 1006.6(d)(1) fixes the assumed permitted window at 8:00 a.m. to 9:00 p.m. local time at the person's location. Second, 12 CFR 1006.14(b)(1) imposes the seven-calls-in-seven-days cap and the seven-day pause after a conversation. Third, 12 CFR 1006.6(b)(1) provides that to the extent the FDCPA or Regulation F requires a debt collector to take a specific action, the collector must retain records evidencing compliance or non-compliance for no less than three years after the date of that action.
Read together, they set a retention floor and two tests that are decided entirely on clock readings. A retention obligation of three years is of limited use if the retained records cannot place an event inside a 13-hour window.
FRE 803(6) is the business records exception. FRE 902(11) allows self-authentication through a custodian's written declaration under penalty of perjury. FRE 901(b)(9) allows authentication through evidence describing the process or system and showing that it produces an accurate result. A system that writes an append-only, server-clocked, millisecond timestamp is straightforward to describe under 901(b)(9); a system with editable rows is not.
One further point on printouts: FRE 1001(d) provides that an original of electronically stored information means any printout or other sight-readable output, if it accurately reflects the information. This is why printing a report does not degrade the record — and also why printing does not strengthen it either. The underlying system record is what carries the weight.
Where a statute requires a contract or other record to be retained, the E-SIGN Act at 15 U.S.C. 7001(e)(1) provides that the requirement is met by retaining an electronic record that accurately reflects the information and remains accessible in a form capable of being accurately reproduced for later reference. The two statutory conditions map directly onto the third and first properties above: the record must not have been altered, and it must still be retrievable.
Take a fleet of 1,000 active subscriptions. At an average of six collection touches per subscription per month, that is 6,000 records a month, or about 72,000 a year. Add three fields to each record — a millisecond timestamp, a time-zone identifier and an origin code — and at roughly 40 bytes per record the additional storage is about 2.88 million bytes a year, or roughly 2.8 MB.
That is the full cost of turning 72,000 records from unresolvable into resolvable. Precision is not a storage problem; it is a design decision made once.
Now take the other side of the ledger. A subscriber alleges eight calls in seven days, which would breach 12 CFR 1006.14(b)(1) if true. With per-call timestamps to the second, the operator can count the calls inside the seven-day window and answer the allegation in one query. Without them, the operator can only assert a number, and the assertion is measured against a record base in which nearly half of each day is unaccounted for.
Check one: are the three columns present. Export the last 100 collection records and look for three fields — a timestamp resolved to the second, a time-zone identifier, and an origin code. Missing any one is a fail. If the export has a single column reading 2026-09-19, then the 45.8 per cent figure above is not hypothetical; it is the actual coverage of your record base.
Check two: compare two clocks. Pull ten records that carry both a device local time and a server insert time and compute the difference. If more than 2 per cent of them differ by over five minutes, clock divergence is the norm rather than the exception, and any determination made on device time is unreliable. Move to server time before anything else.
A screenshot is evidence. A screenshot proves that the image exists; it does not prove that the content is unaltered. The time shown in a screenshot is rendered by the terminal and may differ from what the system holds. What carries weight is the system record behind the image.
Printing it and stamping it makes it an original. Printing does not change anything. FRE 1001(d) already treats an accurate printout as an original of electronically stored information, which means printing adds nothing and stamping adds nothing.
Finer is always better. Granularity is one of three properties, and it is the last one that matters. Millisecond precision from a hand-editable device clock is weaker than second precision issued by a third-party time-stamp authority. The order of assessment is clock source first, immutability second, granularity third.
First, facts the other party admits no longer need proving. If the consumer concedes that a message arrived at 10:30 p.m., the timestamp question is moot for that fact; the precision of the record does not change an admitted fact.
Second, this page describes record-keeping practice and is not legal advice. The federal provisions cited above are a floor, not a ceiling. State law frequently imposes additional restrictions on collection communications, and several states apply their own rules to original creditors as well as to third-party collectors. Keeping good timestamps makes an operator able to answer a question; it does not by itself make the underlying conduct compliant.
We already store the date. Do we really need seconds? Yes. A date answers which day; the two tests that matter — permitted hours and weekly attempt caps — are answered in hours and minutes. A date-only record cannot answer either.
What if the gateway receipts were never retained? Providers keep them for a limited period. Export and archive monthly rather than waiting for a dispute; once the provider's retention window closes, the receipts cannot be recovered.
Is a third-party time-stamp authority required? No. It is an addition, not a starting point. The first three changes — server clock, second-level storage, append-only writes — do not depend on any external service.
How long should records be kept? Regulation F sets a floor of three years for records evidencing compliance where a specific action is required. Longer retention is normally driven by limitation periods and by contractual or state requirements; confirm with counsel. The important point is that the retention period has no gaps and no schema change that drops fields.
Does keeping an edit log fix mutability? Yes, provided the edit log is itself append-only and records the operator and the prior value. An edit log that can be deleted along with the row adds nothing.
LuckyMDM is a device asset management brand of Sichuan Starlight Network LLC, focused on the device subscription, leasing and instalment sectors, with coverage across device control, pre-lease risk screening and post-lease performance management.
For operators in this segment, the dividing line is not how many restriction commands a platform can issue; it is whether every command and every contact can be reconstructed afterwards in a form that survives an outside question. Time fields are the foundation of that reconstructability.
LuckyMDM writes three fields to every collection event record — a server-side UTC timestamp, a time-zone identifier and an origin code — and stores the record append-only; a correction is added as a reversing entry that preserves the original value and the operator identity.