Lending and credit · Specified

The decision: Approve or decline

The payslip said one thing. The bank feed said another.

A residential lending application with two payslips, three months of statements, an employment letter and a valuation. The serviceability calculation works. The documents behind it do not agree with each other.

This is not a customer case study

There is no production tenant and no paying customer. Every document, finding and verdict on this page is synthetic, written to show what the forensic core examines and what a cited verdict looks like. No accuracy or detection figure appears here, because no pilot has produced one under a methodology we would publish beside it. The rule set for this sector is specified, not encoded. The forensic findings below run on any document bundle today; the sector rules do not exist yet.

What arrives

The bundle as it lands, before anybody has read it.

Payslips2 documents, PDF
Bank statements3 months, 47 pages
Employment letter1 page, on letterhead
Identity documents2 documents, images
Valuation report14 pages
Consumer data right feedLive, if consented

What gets examined

The forensic core runs on every document in the bundle regardless of sector. None of these questions changes when the industry changes.

Document lineage Fabrication detection Template comparison Image forensics Sender authentication Registry resolution Cross-file reuse Entity resolution Cross-document reconciliation

What comes back

Every finding carries at least two anchors drawn from at least two separate documents, and the benign explanation that would account for it. A pattern appearing once in one place is not reported at all.

The payslip was not produced by the payroll system named on it Document lineage

The document names a payroll provider in its footer. Its production chain is a general-purpose HTML-to-PDF converter, with no trace of that provider’s output pipeline, and font subsetting inconsistent with every other payslip that provider issues.

Anchored to
  • Payslip 1, document production metadata and embedded font table
  • Payslip 2, same production chain, same inconsistency

The benign explanation: Some employers export a payslip to PDF from a browser rather than issuing the payroll system’s own file, which produces exactly this signature innocently.

Year-to-date figures do not reconcile to the pay periods shown Arithmetic

The year-to-date gross on the later payslip exceeds the earlier one by more than the stated gross for the intervening period. The difference is not accounted for by any allowance, bonus or adjustment line on either document.

Anchored to
  • Payslip 1, year-to-date gross field
  • Payslip 2, year-to-date gross and period gross fields

The benign explanation: A back-paid entitlement, a corrected underpayment or a mid-period pay rise processed as a lump sum would each produce this and be entirely legitimate.

The employing entity was deregistered before the letter was dated Registry resolution

The company named on the employment letter and on both payslips resolves to a registered entity whose status changed to deregistered on a date preceding the letter. The trading name is still in use by a related entity with a different identifier.

Anchored to
  • Employment letter, entity name and identifier
  • Business register, live lookup, status and effective date

The benign explanation: Group restructures leave staff employed by a new entity while letterhead, email domains and payroll templates lag by months. This is common and usually innocent.

The verdict

ESCALATE

Three findings across production, arithmetic and registry, each anchored twice. The application is not declined and no adverse inference is drawn about the applicant. It is referred with the discrepancies stated and a request for the payroll system’s own file.

Where the applicant has consented to a consumer data right feed, the verified income record outranks any uploaded document and the question resolves itself in seconds. That rail exists in Australia and in very few other markets, which is a structural advantage worth building the workflow around.

What it did not do

The same four constraints apply in every sector, and they are enforced in code rather than in policy.

No adverse decision

Nothing was declined, refused, held or approved by the platform. A person decides, on the record, with the reasoning in front of them.

Every sector

No score

No risk number, no ranking, no composite figure. The only number attached to a person is how many independent documents corroborate a fact about them.

Nowhere in the product

No single-source assertion

Two anchors from two documents, or the finding is not reported. This is the largest source of false positives in the category and the platform refuses to generate them.

Enforced at registration

No protected attributes

A detector referencing a protected attribute fails registration and the platform will not start. It is a structural guarantee rather than a policy.

Throws on load

How this gets tested on your own files

Hand us two hundred closed files. Settled claims, funded loans, granted applications, paid invoices, onboarded accounts. We examine them and show you the documents that lied, against outcomes you already know. It is the only honest way to evaluate this category, and it is the same motion in every sector on this page.

The other sectors

Only insurance is built. Every other sector is specified rather than shipped: the forensic core runs on any bundle today, and no rule set outside insurance has been encoded. [email protected]