Tamperlens — measurements from the parser

Everything Tamperlens detects, and exactly what defeats each one

2026-08-20T00:00:00Z

Douglas Haruo · 20 August 2026 · cells derived from src/engine/signals/, not from a marketing sheet

Reference: PDF fraud signals — the field guide

Every vendor in this space publishes what it catches. None of them publish what makes it stop working. This is the second list, for my own engine, in full.

Why publish the manual

The argument against a page like this is that it is a how-to guide for the people I am trying to catch. I do not think that survives contact with reality.

Every command below is on the first page of results for "how to remove pdf metadata". Someone building fake statements for money already owns the tools and already knows which one leaves the cleanest file — that knowledge is what they sell. The people who do not know are the ones on the receiving end: the analyst, the letting agent, the accountant who reads a clean report and hears this document is genuine.

A clean report from a byte-level parser means the bytes are clean. Those are different claims, and the entire risk lives in the gap between them. So here is the gap, drawn to scale.

The five columns

Four of these are the ones people actually run. The fifth is in the table because my own code puts it there.

1. Metadata strip

exiftool -all= statement.pdf

What most people think this does is delete the metadata. What it does to a PDF is append a new revision in which the metadata is blank. The original bytes stay exactly where they were.

A metadata strip on a PDF is an append, not a delete. The revision count goes up by one, and on a signed document the appended bytes fall outside the signed /ByteRange. This is why the tool's own documentation tells you to run a rewriter afterwards.

2. Whole-file rewrite

qpdf --linearize in.pdf out.pdf
gs -sDEVICE=pdfwrite -o out.pdf in.pdf

One revision comes out the other side, with a rebuilt cross-reference table and no history. The two tools are not equivalent, though, and the difference decides five cells in the table below.

A structural rewriter copies through what it does not need to understand — the Info dictionary, the XMP packet, the font objects. A re-renderer regenerates all of it from what it drew. Same column, opposite outcome, and I have not measured which tools sit where.

3. Print-to-PDF

Chromium's Skia backend, macOS Quartz, Microsoft's print driver. The document is rendered and a new file is written from the rendering. Nothing structural crosses over.

The reason print-to-PDF beats most of this table is not subtlety. It throws the evidence away and writes a new file that has never been edited, because it genuinely has not been. What it cannot throw away is the picture — which is where the two families in the last column of the matrix survive.

4. Flatten to raster

Every page becomes one image. No text, no fonts, no structure worth reading. The heaviest hammer available and the only one in this list with a real cost, which I come back to at the end.

5. Encrypt with an owner password

Not a bypass anybody markets, and the one column here that is derived purely from my own source. An encrypted PDF has its strings and streams as ciphertext, so five families are skipped by the engine rather than run on noise. The list is a constant called ENCRYPTED_SUPPRESSED_FAMILIES, and it is five names long.

An owner password does not stop anyone opening the file. It still turns off a third of the engine.

The matrix

Rows are the 12 registered families, in registry order. Eleven of them run on every document; issuer-mismatch only runs when the caller supplies a baseline, and it is the last row for that reason.

gone means the family cannot fire. weaker means it fires with less to say. louder means the evasion itself creates the finding. untested means I could not decide it from the code and have not run the experiment.

The shape, without the reading. Two columns are nearly solid: raster silences almost everything, and the bottom row survives everything. The detail — and the reasons — are in the table below.

Family	Metadata strip	Whole-file rewrite	Print-to-PDF	Flatten to raster	Encrypt
`incremental-updates`	louder — the strip is the second revision	gone — one revision out	gone	gone	fires — the xref chain is not encrypted
`metadata-mismatch`	gone — needs both stores present	untested — copied through, or regenerated?	gone — one writer fills both	gone	gone — suppressed by the engine
`date-anomalies`	gone — no timestamps left	untested — same question	gone — fresh, coherent dates	gone	gone — suppressed
`producer-fingerprint`	weaker — drops to "declares no producing tool", severity low	untested — qpdf keeps the string, a re-render replaces it	weaker — Quartz and Microsoft are on the list, Skia is not	louder — a full-page image escalates the finding to high	gone — suppressed
`id-inconsistency`	untested — does the appended trailer touch /ID[1]?	gone — one save, both halves equal	gone	gone	fires — /ID lives in the trailer
`font-anomalies`	fires — fonts are not metadata	untested — a re-subset would merge the duplicates	gone — one subset per face	gone — no fonts at all	gone — suppressed
`hybrid-page`	fires	fires — the image and the text both copy through	untested — depends whether the printer keeps one image per page	gone — no text layer left to be suspicious about	gone — suppressed
`active-content`	fires — a strip touches metadata only	untested — structural copy keeps it, a re-render drops it	gone — actions are not printed	gone	fires — read from dictionary keys, and the finding says so
`signature-coverage`	louder — appended bytes land outside the signed range	gone — signature destroyed, and nothing reports its absence	gone	gone	fires — /ByteRange is plain
`structure-warnings`	fires — an append repairs nothing	gone — repairing is what a rewriter is for	gone	gone	louder — carries the disclosure and names what was skipped
`redaction-exposure`	fires — the words under the box are content	fires — paint order copies through	untested — the marks half is gone, the covered-text half probably survives	gone — and here the evasion is also the correct fix	weaker — unapplied marks still counted, covered text unreadable
`issuer-mismatch` (needs a baseline)	louder — an absent producer mismatches too	louder	louder — two dimensions move, which is what reaches high	louder — producer and font set both move	louder — suppressed fields read as absent

Three cells worth reading twice

A metadata strip makes two families louder

Because it is an append. The revision count goes from one to two, which is exactly what incremental-updates looks for. And on a signed document the appended region sits past the end of the signed /ByteRange, which is the highest-severity finding the engine has.

Someone tidying a PDF before sending it to me makes the report worse, not better. That is not clever detection on my part. It is the file format.

Removing the producer string does not silence the producer family

With no producing tool declared anywhere, producer-fingerprint still returns a finding: document declares no producing tool, at severity low.

Low is the right place for it, and our own corpus is the reason. Six genuine Huntington account-analysis statements carry no producer and no creator string at all — high-volume composition engines often emit none. An absent toolchain is weakly suspicious and weakly normal at the same time, so it sits at the bottom of the ladder and stays there.

Chromium's print-to-PDF trips nothing, on purpose

The consumer-editor list has around fifty entries. Quartz PDFContext is on it. Microsoft Print to PDF is on it. Skia/PDF, which is what Chrome writes when you print a page, is not.

I know how to close that. I am not going to. When we parsed 213 PDFs published by US banks, two Bank of America online-banking agreements came back as Skia/PDF m130 and Skia/PDF m135 — printed straight out of a browser by whoever maintained the page. Adding Skia to that list turns a real bank's real document into a finding, on a page that is genuinely from the bank.

So printing from Chrome is the cheapest evasion in this table. It costs nothing, takes one keystroke, and my engine says nothing about the tool that did it.

What survives everything

Read the matrix down the columns and the answer is uncomfortable: nothing in the unconditional set survives all five.

Counting only cells marked gone; the untested ones are left out, so three of these bars are floors rather than measurements. Cost is what the evasion takes away from the person sending the document, which is the column that decides whether anyone actually does it.

The one row that survives is issuer-mismatch, and it is the row that needs something the document cannot supply. Every other family reads the file's own account of itself, so rewriting the file rewrites the evidence. That one compares the file to documents from the institution it claims to come from — and all five evasions replace the toolchain a real issuer used.

That is the whole asymmetry, in one sentence: self-description is defeated by regeneration, and comparison to an outside reference is not. The price is that you have to hold the reference. Public specimens mostly do not work for this; documents you already know are genuine do.

The raster trade-off, honestly

Flattening every page to an image silences ten of the eleven. It is the strongest move on the board and I have nothing that beats it.

What it costs is the text layer. No selection, no copy-paste, no extraction, no screen reader. If the document is going into any pipeline that reads the text — an income parser, an accounting import, a reconciliation step — a raster fails on arrival, and it fails before anyone gets to the question of whether it is real.

But that cost lands on the workflow, not on my parser. If a human is going to open the file and look at it, a flattened page sails past everything on this site.

The concession

A full-page raster is not itself reported as a finding, because scanners exist and a scanned document looks exactly like that. On a flattened file the engine is mostly silent, and silence here means I could not look, not I looked and it was fine. If your process accepts raster PDFs, assume this engine is close to blind on them and put the control somewhere else.

One more thing the columns hide: they compose. The strip tool's own documentation tells you to run a rewriter afterwards, precisely because the strip alone leaves the original bytes on disk. Run both and you have removed the metadata and the history in one go. That pair is the realistic attack, and it is cheaper than either of the last two columns.

The cells I could not fill in

Eight cells say untested. They are not hedging — they are the cells where the answer depends on which tool ran, and I have derived this table from source rather than from a bench full of files.

id-inconsistency against a metadata strip — whether the appended trailer rewrites the second half of /ID.
metadata-mismatch, date-anomalies, producer-fingerprint, font-anomalies and active-content against a whole-file rewrite — all five turn on the same unmeasured question, whether the rewriter copies those objects through or regenerates them.
hybrid-page against print-to-PDF — whether the print path emits one image per page or tiles it, which decides whether the page still reads as a full-page image at all.
redaction-exposure against print-to-PDF — the unapplied-marks half is certainly gone; whether the covered text is re-emitted underneath the box is the part I have not run.

Each of those is a morning's work with a fixture set, and when I run it this post gets superseded by a dated one rather than quietly corrected.

The number I will not give you

The obvious next question is what fraction of real document fraud this catches. I do not know, and neither does anyone else selling this.

Every academic benchmark I could find is pixel-level image forensics; there is no PDF-structure equivalent. No vendor publishes a false-positive rate on legitimate documents. The one public figure I have seen is an unmethodologised 80% on a competitor's site.

So the claim is high precision, unknown recall. When a family fires, the report shows the bytes it fired on and you can check them yourself. When nothing fires, you have learned that this particular set of tests came back quiet — which, after reading the table above, you now know how little that can mean.

A finding is a statement about bytes. "This document is fraudulent" is a statement about a person, and a parser does not get to make it.

Run it on a file of your own

The free checker takes a PDF and gives back the same report this table describes, with the raw evidence under every finding. No account, nothing stored.

If you want to see the table hold up, run a document twice: once as you received it, once after printing it to PDF. The difference is the point of this post.

The black box in your PDF is a shape, not a delete key

2026-08-13T00:00:00Z

Douglas Haruo · 13 August 2026

Reference: Check a PDF redaction

There are two ways to black out a name in a PDF. The first deletes the text and then draws a black rectangle where it used to be. The second just draws the black rectangle.

On screen they are indistinguishable.

In the file they are entirely different documents. In the second one every character of the name is still there — selectable, copyable, and extractable by any PDF library in about one line of code.

This mistake keeps reaching production in court filings, disclosure releases and regulatory submissions, from organisations that employ lawyers and document teams. It survives because there is no feedback. The person doing the redacting sees a black box either way, and nothing tells them which one they made until somebody else selects the text.

A constructed pair. Same page box, same coordinates, same rendered result — and in File B the string is sitting in the content stream underneath the rectangle. The name is invented.

A page is a program

The reason the two operations look the same is worth understanding, because it is also the reason you can tell them apart.

A page's content stream is a sequence of operators executed in order onto a blank canvas. A very small one looks like this.

Text, then a rectangle over it

BT /F1 12 Tf 76 660 Td (Dana Whitfield) Tj ET
0 0 0 rg
74 656 130 17 re f

Reading it out: begin text, select font F1 at 12pt, move to (76, 660), show the string, end text. Then set the non-stroking colour to black (rg), build a rectangle at (74, 656) 130 wide and 17 high (re), and fill it (f).

There is no z-index here, and no concept of one object being above another. There is only order. Later paints over earlier. The rectangle covers the name for the same reason a second coat of paint covers the first.

Now swap the two halves.

The same two objects, opposite order

0 0 0 rg
74 656 130 17 re f
BT /F1 12 Tf 76 660 Td (Dana Whitfield) Tj ET

Same objects, same coordinates — and now the name is drawn on top of the black box and is perfectly legible. Which is exactly what a table's shaded header row is: a filled rectangle, painted first, with text on it.

That single fact is the whole of what follows.

The same two operators in the two possible orders. Everything a checker can say about a black box follows from which one it found.

Check it yourself in one line

If you have a PDF with a black box in it, start here.

Does the text come back out?

pdftotext -layout suspect.pdf - | less

If the redacted words appear in that output, they were never removed. That is the entire test, and it is worth running on anything you are about to send.

To look at the operators rather than the text, decompress the streams first. Content streams are Flate-compressed, so strings and grep see nothing useful without this step.

Reading the page as the program it is

qpdf --qdf --object-streams=disable suspect.pdf decompressed.pdf
grep -n --text -E ' (re|f|Tj|TJ)$' decompressed.pdf | head -40

Now you can see for yourself whether the Tj comes before the re f.

The naive version fires on everything

I built the obvious detector first: find dark filled rectangles, find text underneath them, report. It fired on an enormous number of completely honest documents. Every table with a shaded header. Every highlighted paragraph. Every coloured callout box.

Paint order fixes that, and it fixes it by construction rather than by tuning. A background painted after its text would have hidden that text, so it would not be a background. If you can read the words, the shape came first. If the shape came second, it is hiding something.

Four more guards sit on top of paint order in the shipped signal. Each one is there because the version without it produced a false positive on a real document.

Opacity. A highlighter is a filled rectangle painted over text, and it hides nothing. The graphics state carries a non-stroking alpha (ca, set through a named /ExtGState), and a paint has to be at least 90% opaque before it counts as a cover at all.

Size. A covering paint larger than 40% of the page area is a watermark, a stamp or a page background. Without that bound, one document with a full-page DRAFT stamp rendered as an opaque image reported every single line on the page as exposed.

Invisible text. Text rendering modes 3 and 7 paint no glyphs. That is the OCR layer underneath a scanned page — text designed to be invisible on screen and extractable by machine. Those runs are never collected as candidates, because reporting them would fire on every scanned document ever produced.

Image versus drawn shape. A filled rectangle over a line of text is conclusive. An image over a line of text is not: a signature stamp, a logo or a pasted-in scan legitimately lands on top of a word. So a page whose covers are all images still gets reported — one severity band lower, with a note saying why.

There is a size floor as well, because a 2-point fill cannot be hiding a word: a cover has to be at least 6 points wide and 3 tall. And the run has to be genuinely underneath the paint, not merely adjacent — at least 70% of the run's box has to fall inside the cover.

Each branch on the right is a document class the naive detector reported and should not have. The guards are subtraction, not scoring.

Getting the words back out is a separate problem

Finding that a run of text sits under a box tells you there is a leak. Saying what leaked needs one more step, because the bytes inside a Tj string are character codes, not characters, and what they mean depends on the font.

A font can carry a /ToUnicode CMap that maps them.

The content-stream bytes are not text in any useful sense until the font's map resolves them. Synthetic example.

Fonts without a /ToUnicode map are common. There the honest answer is that the coverage is real and the words could not be decoded, rather than a guess. Simple fonts usually turn out to be WinAnsi-encoded, where the byte is the character, which covers most of the practical cases.

The recovered words go back in the response and nowhere else. Files are parsed in memory and discarded with the reply — the evidence lives exactly as long as the HTTP response does.

Things that are not redaction

All of these leave every character in the file.

Drawing a filled rectangle over the text.
Using a black highlighter annotation.
Setting the text colour to match the background.
Placing an image over the area.
Adding a /Redact annotation and never applying it.

The last one is the cruellest, because it is the right tool used incompletely. The annotation is a mark requesting redaction. The content only leaves when the tool applies the marks, and most viewers draw the pending marks as solid black boxes. The half-finished state looks exactly like the finished one, so it is checked first and reported on its own.

What does work: your tool's redaction feature, followed by actually applying it. Or exporting the page to a flattened image, which removes the text layer along with your searchable text.

What this kind of check cannot see

Worth being explicit, because a checker that implies more coverage than it has is worse than none.

Form XObjects. Reusable content blocks are their own little content streams. They are not recursed into, so a covering box inside one is invisible here. Any count is a floor rather than a total, and the report says so on pages that use them.

Already-flattened pages. No text layer, nothing to find — which also means the redaction worked.

Everything outside the page content. A name taken off the visible page can still be sitting in the document metadata, an attachment, a form field, or an earlier revision of the file. Different problem, different checks.

There is one more approximation worth naming. No font width array is loaded, so glyph advance is assumed to be half an em. A run whose width is misjudged by a fifth still passes or fails the 70% test the same way, because redaction boxes are drawn with generous margins around what they hide.

Nothing on this page describes a real document, organisation or person. The examples are constructed and the names are invented. This post is about a class of mistake, not about anybody's filing.

Try it on a file whose history you know

I built the redaction check because I got tired of running the qpdf/pdftotext dance on documents people sent me and wondering whether I had missed one. It walks each page's content stream tracking the transformation matrix, fill colour, alpha and paint order, computes boxes for the text runs, and reports the runs that ended up under something opaque — with the recovered text, because if a checker can read it so can anyone who received the document.

The most useful four minutes you can spend with it: take a document of your own, draw a black rectangle over a line in whatever editor you have, export it, and check that. Watching it recover words from a file whose history you personally know is worth more than this post.

Check a PDF redaction — free, nothing stored, and a fictional sample opens automatically so you can see the output before deciding whether to trust it with anything of your own.

What 190 published US bank PDFs actually look like inside

2026-08-06T00:00:00Z

Douglas Haruo · 6 August 2026 · corpus collected 26 July 2026

Reference: PDF fraud signals — the field guide

Every serious document-fraud product has a model of what a real document from a given institution looks like. Resistant AI calls it MODEL_MATCHED. Inscribe has TEMPLATES and FINGERPRINT. Snappt claims 2,000-plus institutions.

The idea is simple enough to be irritating. If you know a Chase statement is always produced by a particular composition engine, at a particular PDF version, with a particular font set, then a file claiming to be a Chase statement and produced by Microsoft Word is worth a second look.

I wanted that, and I did not want to build it on a guess. So I downloaded 213 PDFs from 24 US financial institutions' own domains and parsed every one.

The result is split, and the half that failed is the more useful half.

For documents banks publish on their websites — fee schedules, account agreements, privacy notices, brochures — there is no usable issuer fingerprint. Across the 17 profiles with at least five samples, zero reached 80% agreement on the producer string. One reached it on the font set. Bank of America's nine documents carry seven distinct producer strings. Marcus's twelve carry ten.

For the one genuine statement pipeline in the corpus, the fingerprint is sharp. Six Huntington account-analysis statements agree 6/6 on PDF version, cross-reference style, page size, revision count and linearisation, 5/6 on the exact font set, and 6/6 carry no producer or creator string at all.

So the premise holds — but only for statement output, which is exactly the class of document you cannot get from a bank's website. I obtained a real statement pipeline for one of the 27 institutions I tried.

None of what follows is a claim about US banking. It is a description of 190 specific files. I am publishing it mostly because the negative result is the actionable one: it tells you which document classes a fraud baseline must not be built from.

The caveat that governs everything else

A marketing or disclosure PDF is not evidence about a statement pipeline.

Banks compose customer statements on dedicated output-management systems that run unattended at volume. They compose fee schedules and brochures in desktop publishing tools, over fifteen years, using whatever the marketing team had.

These toolchains have nothing in common but a logo.

The two toolchains a bank runs. A baseline drawn from the right-hand column cannot describe the left-hand one, and this corpus is mostly made of the right-hand column.

Which means: build a "Chase baseline" out of Chase fee schedules, test a genuine Chase statement against it, and you flag the genuine document. That is not hypothetical — it is what this corpus is mostly made of.

The corpus by document kind. The class the whole technique depends on is the second-rarest thing in it.

That is why a profile's identity is <issuer>-<documentKind> and kinds are never merged. A profile named chase-disclosure announces in its own name that it is a baseline for Chase disclosure PDFs and not for Chase statements.

If that seems like an excess of caution, consider the alternative: a confident mismatch finding on a real customer's real statement.

What the corpus is

27 institutions attempted; PDFs obtained from 24 domains; 23 issuers with at least one US-entity sample.
213 files, all from the institution's own official domain. 23 from non-US arms (TD Canada, Amex Australia and Austria, Citi EMEA, BNY EMEA, USAA EU and UK) are excluded from every profile, which is what leaves 190.
Nothing from a template site or a document-sharing site. No real person's statement was obtained, and none is needed — everything here is a published specimen or a public disclosure.
Every sample's source URL, size and SHA-256 is recorded, and a --check mode re-derives the whole data set from the files and fails if it has drifted.

Institutions I could not get usable data for: Wells Fargo statements (only generic site PDFs), Charles Schwab, SoFi, Chime, Goldman Sachs' institutional site, and TD Bank US — every TD PDF I found belonged to TD Canada.

Citi and American Express are represented by two and one US samples, which is not enough to say anything, and I am not going to.

Finding 1 — producer strings are not an issuer tell for published documents

The /Producer string names whatever wrote the PDF bytes. It is the first thing anyone reaches for, and across 190 files it looks like this.

"Everything else" is Nitro, PDF-XChange, QuarkXPress, PDFCreator and, in one file, a Ricoh copier. These are 190 documents published by banks.

Per institution, the spread is the finding.

A full bar means every document had a different producer. KeyBank: eight documents, eight producers, not one repeat.

The font sets behave the same way. Across those same seven institutions the counts are 9, 11, 16, 8, 11, 9 and 6 distinct font sets — in three cases one per file.

Two Bank of America online-banking agreements were printed straight out of a browser — Skia/PDF m130 and Skia/PDF m135, with creator strings that are literally Chrome user-agent strings.

Chase serves card rate-and-fee tables produced by Apache FOP, a server-side XSL-FO renderer — a real automated pipeline — sitting alongside brochures out of Adobe InDesign. Two document classes, one issuer, nothing in common.

The implication is uncomfortable and worth stating plainly: a document whose producer is "Microsoft Word" or "Chromium" is not, on that basis, anomalous. Real banks publish such files constantly. If you have seen a fraud vendor imply otherwise, that is the claim to press on.

Producer strings become evidence only when the baseline is drawn from the same document class — and, as Finding 3 shows, then they become good evidence. The metadata forensics guide covers what /Producer and /Creator are specified to mean, and where each one is written twice.

Finding 2 — font sets are near-unique per document, not per issuer

I expected the font set to be one of the strongest tells, on the theory that fonts follow from a template.

In this corpus they mostly follow from the document. 190 samples yield 167 distinct font sets, of which only 12 occur more than once. The top-ranked font set reaches 80% of samples in exactly one profile out of 17 — the Huntington statements.

Brand fonts do show up, and they are genuinely distinctive when they do: PNCBrand, DiscoverSans, CitiSans, Connections (Bank of America), Optimist (Capital One), M&TBalto, Huntington_Apex. A file claiming to be from Capital One with no trace of Optimist is a reasonable question to ask.

But the brand font appears alongside a different supporting cast in almost every file — whatever the author's machine had — so the joined set almost never repeats. And it is the joined set you would have to match on.

Finding 3 — the one real statement pipeline is sharply consistent

Huntington publishes six sample account-analysis statements — commercial treasury statements, not consumer checking — as raw pipeline output rather than a redrawn mock-up. Somebody exported them from the real system and put them on the website.

The huntington-statement-specimen profile

producer        (none — 6/6 carry no producer string)
creator         (none — 6/6)
pdfVersion      1.6                      6/6
xrefStyle       stream                   6/6
pageSize        612x792                  6/6
revisionCount   1                        6/6
linearized      true                     6/6
signed          false                    6/6
fontSet         EX_CFF_Arial|EX_CFF_Calibri|EX_CFF_CalibriBold|
                EX_CFF_Huntington_Apex_Medium|Helvetica|ZapfDingbats    5/6

Two things stand out.

The complete absence of producer and creator metadata is itself the signature. High-volume composition engines frequently emit none; nearly every desktop tool announces itself by name and version. An empty /Producer is not a null result here, it is a positive one.

The EX_CFF_ font-name prefix is an artefact of the composition engine's font handling, not of any font a human chose. Neither would be reproduced by accident by someone building a fake statement in Word or a browser.

That is what a usable baseline dimension looks like: stable within the issuer, and not reproducible without the issuer's toolchain.

One institution, one statement product. It does not generalise. But it is a concrete existence proof that the signal this feature depends on is real where it matters.

Finding 4 — customer-communication platforms are visible, and distinguishable

A handful of samples were produced not by desktop software but by customer-communications management platforms — the same category of tooling that generates statements.

PNC: Smart Communications - SC33 / SC31, on four consumer documents.
USAA: xPression 4.6SP1, an OpenText composition engine.
Wells Fargo: Crawford Technologies, OAT.
Navy Federal: Accessibil-IT Inc., an accessibility-remediation post-processor.

These strings are rare in general-purpose PDFs and hard to produce accidentally. PNC is also the tightest of the seven institutions above — three producer strings across eight samples, against KeyBank's eight across eight.

Where a bank routes even its disclosures through this tooling, its published documents sit structurally closer to its statements than a typical brochure does. I have no statement from any of those institutions to confirm it against, so treat that as a hypothesis with a clear test rather than a result.

Finding 5 — what is uniform is uniform because it is uniform everywhere

Among the 17 profiles with five or more samples, this is how many reach 80% agreement on each dimension.

dimension	profiles reaching ≥0.8
signed	17 / 17
pageSize	11 / 17
linearized	10 / 17
revisionCount	9 / 17
xrefStyle	5 / 17
pdfVersion	3 / 17
fontSet	1 / 17
producer	0 / 17
creator	0 / 17

Not one of the 190 documents is digitally signed. signed is perfectly consistent and therefore worthless as an issuer discriminator: everyone matches it, forgeries included. pageSize is mostly US Letter — 612×792 in 152 of 190 — for the same reason.

This is the trap in the whole approach, and it is easy to fall into if you grade yourself on agreement scores. A dimension stable across all issuers carries no issuer information.

The useful ones are stable within an issuer and varying between them. In this corpus only the Huntington statement set demonstrates that pattern.

One more number, because it contradicts something people repeat: 142 of 190 documents are single-revision, but 48 are not, and one carries 24 revisions. Multiple revisions in a genuine, published, bank-originated PDF are ordinary.

If you are counting %%EOF markers and treating two as suspicious, this corpus is your counterexample set. The edited-PDF guide explains the two directions that count is wrong in, and what to walk instead.

What this data can and cannot support

It can support:

That issuer structural baselines are viable for statement output.
Calibration of what normal looks like for published bank PDFs, useful mainly for suppressing false positives on documents that are not statements at all.
A concrete argument that baselines must be built per document class, and named that way.

It cannot support:

Any claim of the form "Bank X's statements use producer Y" for any bank other than Huntington's account-analysis product — and not for Huntington's consumer statements either.
Percentage claims about US banking. 23 non-randomly sampled issuers is not a population.
Detection thresholds. With 16 of 17 eligible profiles failing the consistency gate on producer, the honest engine behaviour is to produce no expectation at all, which is what it does.

What we shipped, given all that

The issuer-baseline feature is live and labelled experimental, disabled as a production default.

Of 56 profiles, 39 sit below the minimum-samples threshold and can only ever report unknown. Of the 17 that clear it, 16 are built from disclosure, marketing and form documents whose internal consistency is too low to produce a mismatch on the dimensions that matter — so they will also, correctly, stay quiet.

The operational value of this data set today is close to exactly one profile.

That is a strange thing to ship. The reason it shipped anyway is that the parser, the build script and the provenance format are the scaffolding for the data set that will actually work: tenant-supplied known-good statements.

If you hold originals — a lender with a year of real statements from the banks you actually see — those are the documents this was designed for, and a baseline built from them has none of the problems above. Structurally it is the same operation as comparing two files you both trust, run across a set instead of a pair.

That path is on the paid plans, and it is the only version of this feature I would defend.

The limits you should hold this against

A cleanly re-generated PDF launders every signal described here. Print-to-PDF or save-as rewrites the byte structure; the revision chain, the /ID pair, the producer string and the font-subset tags all come out coherent and fresh. There is no version of this technique that survives that, and anyone telling you their version does is selling you something.

Nobody has measured what fraction of real document fraud structural analysis catches. The only public figure I know of is one vendor's unmethodologised "80%". Every academic benchmark I could find is pixel-level image forensics; there is no PDF-structure equivalent. The defensible claim is high precision, unknown recall, and I am not going to put a number on the second one.

This reports signals, never a verdict. "The producer string does not match this issuer's baseline" is a statement about bytes. "This document is fraudulent" is a statement about a person, and it is not one a parser gets to make.

Run the same parser on a file of your own

Every number above came out of the parser that runs on the free checker. Drop in a PDF and you get the same report this corpus was built from — producer and creator strings, the revision chain, the font sets, page geometry. No account, nothing stored.

Everything in this post traces to a specific file with its source URL and SHA-256. If you hold a corpus of genuine statements from an institution and want to know whether it produces a usable baseline, that is the same measurement, run against documents you supply.