Auditing an Audit Trail: Y'all Forgot to Run Spellcheck on Your Faked Documents

In September 2025, I reviewed a lending contract. Never mind that the lender misspelled their own city (Rosenberg, TX) and listed an APR of 102.16%—what caught my eye was the borrower’s signature. It was just the borrower’s name in italicized font. I won’t reveal the borrower’s name, but here’s what it looked like (using the fake name of “Adam Smith”):

That does not, by itself, prove anything nefarious. Electronic signatures can take many forms. A typed name, click-to-sign mark, stored facsimile, or platform-generated signature can all be perfectly legitimate depending on the process behind it.

So, I gave them the benefit of the doubt. In an email, I conceded that the typed “signature” was likely a digital placeholder, but I would need “the digital certificate, transaction ID, and audit trail to establish: who signed, when they signed, the IP/device/browser used, and the hash values of the document at time of signing.” When the visible mark does not explain itself, the execution record has to.

On September 8, 2025, I emailed Sun Loan and asked for the materials that would ordinarily make an electronic execution testable: the digital certificate, transaction ID, audit trail, signer IP information, device or browser information, and document hash values. I framed the request under ESIGN/UETA and statute-of-frauds principles, including Texas authority such as Khoury v. Tomlinson. I was throwing down the gauntlet; if this signature was real, prove it.

Two days later, Sun Loan’s Credit Dispute Department answered on letterhead, stating:

Attached you will find a copy of the certificate, transaction ID and audit trail for verification of the loan.

Good. That was exactly what I had asked for.

Then the package began making its own case against confidence. Even though the cover letter contained only a single substantive sentence, the author somehow managed to misspell the borrower’s name (a pattern is emerging here). Typos happen. I make them. Lawyers make them. Entire courts have issued them. But a verification package is supposed to reduce uncertainty, not contribute to it.

The ‘audit trail’

Inside the packet was a page branded “Sun Loan Funding, Ltd. Audit Trail.” It advertised a campaign titled “Your Document Is Ready For Signing” and then, just one line below, it read “STATUS: COMPLETED.” I guess it self-executed between rows 1 and 3.

A man without a country, a UUID without an envelope.

The document contained a “Document ID” number, but lacked attribution to a valid document verification service; just a random identifier taking up space and trying to look official. Major e-signature systems ordinarily use their own transaction vocabulary and issue completion records that connect the identifier to the platform, events, signers, and document integrity. Here, the page simply calls the value a DOCUMENT ID.

No vendor is identified. No envelope certificate accompanies it. No cryptographic hash shown on the page ties the identifier to the loan PDF I was being asked to trust. A long hexadecimal-looking thing is not provenance merely because it has hyphens.

Sent via Text. LOL.

Legitimate document execution platforms route authentication links through dozens of encrypted secure channels. "Text" ain't one of them.

Audit logs use strict, standardized industry terminology. If a document is sent to a mobile device via a text message link, the audit trail will denote the delivery and authentication method using the following technical phrasing:

"SMS" or "SMS Delivery": This is the universal technical term platforms use. In the recipient details or delivery logs section of the audit trail, it will explicitly list "SMS" as the channel used to send the notification.

"Authentication: SMS Auth": If the system was configured to require the user to enter a passcode texted to them before signing, the record will explicitly note "SMS Authentication" alongside a timestamp of when that code was sent and verified.

Oops again, Sun Loan.

Timestamps suffering an identity crisis.

Every row uses a timestamp in the same style:

04:04:52 PM EST

Seconds precision. AM/PM. A zero-padded hour. A three-letter time-zone abbreviation.

It is an impressively busy little timestamp.

In ordinary 24-hour (military) time, 04:04:52 means four o’clock in the morning. There is no “PM.” Afternoon would be 16:04:52. In ordinary 12-hour civilian time, afternoon is 4:04:52 PM — usually without a leading zero on the hour, and never confused with 04:xx as a morning military stamp.

The format itself is not proof of fabrication; zero-padded 12-hour clocks exist. In programming date formats, uppercase HH (i.e., “HH:MM” time formatting versus “hh:mm” time formatting) usually means a 24-hour clock and lowercase hh a 12-hour clock; pairing a true 24-hour hour with AM/PM would be incorrect. The printed page alone does not show which token was used.

More importantly, every event is stamped EST.

The loan branch is in Rosenberg, Texas. The signer (borrower) lives in Texas. Sun Loan is in Texas. Texas observes Central Time. A system can certainly log in a server’s default time zone (usually UTC, not EST). That would be a perfectly ordinary explanation. But why a time zone that has no relation to the lender, the lending institution, or the signer? Audit EST, over and over, while telling a Texas loan story. Not necessarily wrong. Just one more question the document creates rather than answers.

And while we're at it, let's talk about locations, specifically IP addresses...

“IP Addess.” ADDESS? Are you f***ing kidding me.

I could conceive of an argument for each of the above points. But, "Addess"? I was immediately reminded of the Joker's line in The Dark Knight: "This town deserves a better class of criminal."

This is supposedly an audit trail—a precision record offered to establish the authenticity of a disputed electronic signature. If there is one genre of document where proofreading is not merely decorative, this would seem to be it. And, if you were going to forge such a document, I'd think you'd be extra careful. But, apparently not at Sun Loan.

Continuing, the contents of the "IP AddRess" (I really can't get over that) column are also interesting:

The SENT event has no IP address. That's strange because it immediately breaks the chain of custody—one of the foundational elements of a document verification service.

I've blurred them, but the AGREED, VIEWED, and SIGNED events all repeat exactly the same IP address. It's an IPv4 address (which is important).

An IPv4 address is an older, 32-bit numerical identifier written as four numbers separated by periods (e.g., 192.0.2.1). Because it only allows for about 4.3 billion unique combinations, the world ran out of new IPv4 addresses as the internet grew.

An IPv6 address is the modern upgrade, utilizing a 128-bit structure written as eight groups of hexadecimal numbers separated by colons (e.g., 2607:fb90:e102:445a:ad43:a32c:119f:9b21). Because billions of smartphones require their own unique identifiers, major cellular carriers migrated to IPv6-only mobile networks. When a device connects via mobile data, it is automatically assigned one of these massive IPv6 blocks to ensure seamless, direct routing without needing the shared, recycled addresses common to older IPv4 setups.

This means that, if Sun Loan had sent a contract for signature via "text" and the borrower opened it on his phone, the IP address in this column should be an IPv6 address not an IPv4 address.

Now, I know that an IP address is network evidence and does not always resolve to reveal a specific user or location. It can identify an internet connection or network endpoint with varying degrees of usefulness; it does not tell you, standing alone, which company employee sent something or which human being was holding the device.

That said, I still was curious and geolocated the IP address that Sun Loan listed. The results are not definitive but are still interesting:

Maybe the metadata can help

The metadata does not identify DocuSign, Adobe Sign, or another recognized e-sign completion-certificate producer. Instead, it tells a printing story.

An earlier XMP layer says the PDF was created on September 10, 2025 at approximately 3:39 p.m. Central using a Windows PostScript printer driver: PScript5.dll 5.2.2 It was distilled through: GPL Ghostscript 9.06 The creator name in that layer is: melissa The PDF Info dictionary was then rewritten the next day. It lists:

Author: shelbi Creator: Adobe Acrobat 25.1.0 Producer: GPL Ghostscript 8.15

So the verification PDF carries two human names in two metadata layers—"melissa" and "shelbi"—neither of whom appears in the body of the letter, the audit trail, or the email thread. That does not prove either person created the supposed 2024 signature event. It does prove something much narrower and much more useful: human accounts touched the verification package in September 2025. That is provenance. And provenance is exactly what the “audit trail” itself was supposed to be supplying. So, there's that, I guess.

Not an audit trail, according to the audit trail

Sun Loan had one little nugget left for me, just to cap it all off. At the bottom of the page, it declared itself a "non-authoritative copy." That is an extraordinary label to place on a document being offered as proof of execution. "This thing that we say proves everything? Don't rely on it." So, even if the document was valid, Sun Loan specifically defeated the entire purpose it sought to serve.

What a serious audit trail is supposed to do

An audit trail should be the boring part. It should end the argument. It should identify the signing platform, tie the signer to a transaction or envelope, record the relevant events, preserve meaningful authentication data, and connect the executed document to some reliable integrity mechanism—a certificate, hash, cryptographic seal, or comparable provenance record. In other words, when someone challenges an electronic signature, the audit trail is supposed to make the mystery go away. This one multiplied it.

Sun Loan produced a document bearing Sun Loan Funding’s own branding, a generic campaign title, a UUID called a “Document ID,” a misspelled “IP Addess” column, a bare IP address repeated across three events, unexplained EST timestamps for a Texas transaction, no identified signing vendor, no browser or device information, no displayed document hash, and no independent certificate tying the supposed signing event to the loan document.

Then, apparently concerned that subtlety had not yet completely left the building, it stamped the thing: NON-AUTHORITATIVE COPY.

The metadata did not rescue it. Instead of revealing the provenance of some pristine 2024 execution certificate, it showed a September 2025 Windows print-to-PDF workflow involving accounts named melissa and shelbi.

None of those facts, standing alone, proves that somebody fabricated the underlying loan. That distinction matters. A typo is not forgery. An IPv4 address is not forgery. A strange timestamp is not forgery. Ghostscript is not forgery. Even a spectacularly unfortunate NON-AUTHORITATIVE COPY footer is not, by itself, forgery. But authentication does not work by asking whether every individual anomaly can be given an innocent explanation. It works by asking whether the evidence, taken together, reliably establishes what its proponent says it establishes.

And that is where this thing falls apart.

The document that was supposed to answer the question became the question

I asked Sun Loan for evidence showing who electronically signed the contract, when, through what system, from what device or browser, and with what evidence tying the resulting document to that execution. Sun Loan said it was sending me the certificate, transaction ID, and audit trail. What arrived was a self-branded PDF whose own origin required forensic reconstruction. That is the part I cannot get past. The entire purpose of an audit trail is provenance:

Who did what? When? Through what system? To what document? And how do we know?

Instead, the supposed provenance record arrived with provenance problems of its own. For a document produced specifically to settle that question, that is a fairly spectacular failure. Or, to put it another way:

If your proof of authenticity needs its own authenticity investigation, you have not solved the problem. You have just added another exhibit.