The Payslip That Was Edited Before It Reached the Lender
By Ergini, Software & AI Developer
A composite story. The company and the people in it are invented. The problem, the rules and the system are real, and the full blueprint is in the use case library.
TL;DR
A composite story: an invented used-car lender near Frankfurt approves an applicant whose July payslip was edited after his payroll software created it, and delays an honest nurse whose phone-scanned payslips a detection tool scored as suspicious. The check I would build does not ask a model whether a document looks fake. It tests what each payslip claims against payroll arithmetic, file structure and the applicant's own bank data through open banking, combines the signals with versioned rules, and pauses contradictions for review. A person decides every case, and nothing is declined automatically.
Two files at 14:05
Elif reviews loan applications for an online lender near Frankfurt that finances used cars for private buyers. The lender is invented: thirty people, around 1,500 applications a month, each with three payslips, two months of bank statements and an identity check through a KYC provider. Elif and two colleagues look at every file the credit rules let through, at roughly eight minutes a file.
At 14:05 on a Tuesday she has two of them open side by side.
The first is Sven's, a warehouse shift supervisor who wants €18,000 for a three-year-old estate car. His payslips are crisp PDFs from his employer's payroll software, and July shows net pay of €3,480.
The second is Agnieszka's, a nurse at a Frankfurt hospital who moved from Wrocław in the spring. Her payslips are photos from a scanning app, merged into one PDF, one page slightly crooked. The oldest is in Polish, from her previous job.
For a month the lender has been trying out a tool that scores each upload for manipulation. Sven's file scores 0.12. Agnieszka's scores 0.87. Elif approves Sven and asks Agnieszka for "better copies", which in practice means her file waits a week.
Four months later, the same two files
Four months later Sven's loan is two payments behind, and the collections team reads his file properly for the first time. The net pay on the July payslip is higher than the gross pay of €3,050 printed a few lines above it. His May and June payslips say €2,140, and so does the July salary credit on his own bank statement, two PDFs further down the same file. Someone in IT opens the payslip's structure: it was saved a second time after the payroll software created it, by an online PDF editor.
Agnieszka was exactly who she said she was. She took a loan from another lender two days after the request for better copies.
So the tool was wrong in both directions, which detectors often are: they miss careful edits of real documents and flag honest scans. But the worse problem is what it gave Elif. A score of 0.87 is not something she can check, and it is not a question she can put to a nurse. The evidence that would have paused Sven's application was in his file the whole time, and eight minutes a file leaves no time to compare one PDF with another.
A better detector is the wrong fix
Stefan, who runs risk, calls me after the collections review. He wants a better detector, and I understand why. Fakes have become cheap: AppZen, which sells expense auditing software, reported that AI-generated receipts went from none of the fraudulent expense documents it flagged in March 2025 to 70.8% by mid-May 2026. A payslip is the same kind of document: a template, some numbers and a logo.
But I would not build him a better detector. I would stop asking whether a document looks fake and start testing what it claims against things the applicant does not control. The payslip claims an employer, a gross figure and a net figure. The bank either paid that net figure in or it did not.
There is a legal reason as well as a practical one. GDPR Article 22 restricts decisions based solely on automated processing, and in its SCHUFA ruling of December 2023 (C-634/21) the Court of Justice held that a score can itself count as such a decision when a business draws strongly on it. A lender that turns applicants away because a tool said 0.87 walks straight into that question. In what I build, no score refuses anyone.
What the July payslip claims, and what disagrees
Every upload lands in quarantine storage first, is virus-scanned and hashed, and is opened by nothing but the parsers until the checks are done. Code takes the file apart: revisions and incremental saves, the software that produced it, the font subsets line by line, hidden or white text, and hashes compared with every earlier upload.
Then a model reads the document into the claims it makes: employer, pay period, gross and net pay, IBAN, account holder. That is the only thing it does with the payslip. Any instruction it finds in the text, such as a hidden line telling an AI reviewer the document is verified, is recorded as data and becomes one of the strongest signals in the file. Code tests the claims against each other, and then against the world: with the applicant's consent, the bank's own data through an open banking provider, the KYC result, and the lender's own application history.
Here is Sven's July payslip, as the reviewer would see it:
| Check | Source | Result |
|---|---|---|
| Payroll arithmetic | Code | Net pay of €3,480 exceeds the gross pay of €3,050 on the same payslip |
| Bank data | Open banking, with consent | Salary credits from the employer of €2,140 in May, June and July: the July payslip is contradicted |
| File structure | PDF forensics | Saved again after creation by an online PDF editor; net pay set in a different font subset |
| Other payslips | Forensics and arithmetic | May and June produced by payroll software, consistent with each other and with the bank |
| Reuse | Earlier applications | No exact or near match |
| Tier | Versioned rules | Strong contradiction: senior review, application paused, automatic decline not permitted |
The bank data is the row that matters most. The uploaded statement already disagreed with the payslip, but a more careful applicant would have edited the statement too. Nobody edits the bank's own record. The full set of checks, and how each one misfires, is in the blueprint for document fraud detection.
Agnieszka's file, run again
The checks have to be fair to her, or they are not worth building. Her merged PDF raises a file-structure signal, because a scanning app wrote it. That signal is soft by design: phone scans, compression to fit an upload limit and merged files are how honest people send documents. A soft signal leads at most to a request for the bank's original download, never to a decline. Her arithmetic reconciles, and with her consent the bank data shows salary credits that match her German payslips.
Her Polish payslip is not a signal either. An unfamiliar format goes to a reviewer who reads the language, and review and decline rates are monitored by the country a document came from, so a check that quietly leans on foreign applicants shows up in the numbers. If she declines open banking, which she may, because consent made a condition of applying is hard to call freely given, she gets another route: the bank's original PDF download plus a statement from her employer. Declining is never counted against her.
None of this routes a case at first. For the first weeks the checks run in shadow: every signal is computed and logged while Elif and her colleagues review exactly as before, and the thresholds are set from what they actually find. That is where the re-save signal is exposed. It fires far more often on honest applicants than on anyone else, so it stays soft, and from then on false positives are tracked per signal. A signal that mostly flags honest people is reweighted.
The file never says forged
A model writes the reviewer's summary, but only from the signals, and every sentence links to the signal it came from. For Sven it would say that the July net pay is contradicted by the salary credit in his own bank data and exceeds the gross pay on the same payslip, that the file was edited after creation, and that May and June are consistent. Suggested next step: ask him to explain the July figure, or to provide a statement from his employer.
It does not say fraud, because the system does not know that. Payroll corrections and back pay can make honest arithmetic look broken, and people re-save files for harmless reasons. So the system states what disagrees with what, and people decide what it means:
- Elif decides every flagged case: accept, ask for more, or decline with a reason code. A hard contradiction pauses the application and goes to senior review. Nothing is declined automatically.
- Requests for more evidence stay generic. An applicant told about one specific anomaly learns what to fix next time, so re-uploads are compared with earlier versions and the rule weights stay inside the team.
- Compliance owns anything outside the company. A report of suspected fraud has legal consequences and needs their sign-off.
Applicants are told before they upload that documents are checked for authenticity, automatically and by people, and which outside sources are used. A data protection impact assessment comes before launch. And the fraud check stays separate from the credit score: the EU AI Act treats credit scoring of individuals as high-risk, with an explicit exception for systems that detect financial fraud, and the Digital Omnibus moved those high-risk obligations to 2 December 2027. Keeping the two apart means the exception is never stretched to cover a system that ranks applicants.
Another Tuesday, 14:05
Elif still has two files open side by side. The difference is what sits next to them. Sven's would be paused with three rows of evidence and a question to send. Agnieszka's would go through, or wait a day for one original download. The files with no signals continue with their evidence stored, and her eight minutes go to the files that need them.
If one risk dominates, buy for it. Identity documents and selfies are the home ground of KYC vendors such as Onfido, now part of Entrust, and IDnow; US lenders on Encompass will find Ocrolus a natural fit; Resistant AI and Inscribe sell document forensics trained on more statements than one lender will ever see. What no vendor sells is the cross-check against your own data: the open banking provider you already contract with, your application history and a review queue inside your loan system. Often the answer is both, with a vendor's forensics API as one signal inside your own pipeline.
That pipeline is an AI integration into the systems you already run, usually in its upper tier, because the work is in the connections, not the model. The full blueprint has every check and how it misfires, and the hidden-instruction problem is covered in prompt injection defense.
Frequently asked questions
Can AI detect an edited payslip?
Not by looking at it. What catches edits is testing what the payslip claims: gross-to-net arithmetic, whether the file was saved again by a PDF editor, a figure set in a different font, and above all the salary credits in the applicant's own bank data, read through open banking with consent. A model reads the payslip into fields, code runs the checks, and a person decides.
How do you detect an edited PDF?
By reading the file's structure rather than its appearance. Incremental saves show a document was changed after it was created, producer fields name the software that saved it, font subsets reveal numbers typed in later, and hidden text shows up in the drawing instructions. Each has innocent explanations, such as phone scanning apps and merged files, so they are signals for a reviewer, not verdicts.
Can a lender decline an applicant because of a fraud score?
In the EU it should not. GDPR Article 22 restricts decisions based solely on automated processing, and in its SCHUFA ruling (C-634/21) the Court of Justice held that a score can itself count as such a decision when a business draws strongly on it. A fraud check should pause cases and route them for review, with a person deciding every refusal.
Should a lender buy a document fraud tool or build one?
Buy for a single dominant risk: a KYC vendor such as IDnow or Onfido for identity documents, or Ocrolus for US mortgage files. Build when the strongest evidence is your own: the open banking data you already contract for, your application history and your review queue. Often the answer is both, with a vendor's forensics API as one signal inside your own checks.