
Tackling AI Invoice Fraud with Privacy Preserving Encrypted Compute
Learn how Open Banking and privacy-preserving encrypted compute can combat AI-generated invoice fraud by verifying that a payment actually occurred. Silence Laboratories’ CCVM matches expense claims against bank or payment-provider records while keeping employee statements and sensitive financial data private.

Written by
Kush Kanwar
Insights
Aug 21, 2026
Finance teams have quietly lost the ability to trust what a document looks like. AI now produces pixel-perfect invoices: correct logos, valid GST formats, matching fonts, clean metadata. They pass every visual check and every automated one. In September 2025, 14% of falsified expense documents were AI-generated [Source], up from effectively zero a year earlier. The relevant question is no longer "does this look real?" It's "did this transaction actually happen?"

The old controls assume something that's no longer true
Traditional expense controls rest on a single assumption: that a convincing document is hard to produce. Auditors eyeball receipts for legitimacy, systems match amounts against policy limits and flag duplicates. Every one of these checks treats the document as evidence. That assumption is now false. AI-generated invoices defeat human reviewers and rule-based engines alike, because the artifact being inspected can be manufactured on demand at zero cost and near-perfect fidelity.
The intuitive fix is to stop trusting the document and confirm the payment behind it actually occurred.
No document scanner, however good, wins this race. Once the fake is pixel-perfect, the document stops being evidence. The only reliable answer is to go to the source and ask whether the payment actually happened, which means connecting to the bank or payment provider rather than inspecting the PDF.
That's where Open Banking comes in

Open Banking is the rail that already solves the access problem in a regulated, consent-driven way. Rather than asking employees to upload a document or hand over a statement, the payment record is confirmed directly at its source, the bank or payment provider, through standardized, licensed APIs. The employee grants scoped, purpose-bound consent for a single check, and the account aggregator layer releases only the matching transaction. The infrastructure, the consent flows, and the regulatory backing are all live today. What's been missing is a way to use that record for verification without the employer ever taking custody of it.
Companies can't access employees' bank statements, and they shouldn't want to. Raw financial data sitting inside a reimbursement tool is a serious privacy liability, exactly the kind of sensitive dataset a company is better off never holding.
Verify the payment without seeing the statement

There's a way to get the verification without the exposure. Combine Open Banking, which can confirm that a payment record exists, with Silence Laboratories' Cryptographic Computing Virtual Machine (CCVM), which checks the claim against that record while the data stays encrypted. The employer confirms the payment happened without ever seeing the underlying statement.
The claim fields and the bank or payment-provider records are matched cryptographically. Each side contributes only encrypted data; neither party sees the other's dataset. What comes back isn't a data dump, it's a narrow verdict:
Transaction: Yes
Amount: Matches
Date: Matches
Merchant: Matches
The employee gives purpose-bound consent and controls exactly what is shared. No full transaction history moves to the employer. The company gets verification and inference; the employee keeps their financial privacy intact.

How it works
The end-to-end flow pairs Open Banking with Silence Laboratories' Cryptographic Computing Virtual Machine (CCVM). The process runs as follows:
Request consent. The employer's expense platform submits a verification request tied to a specific claim record (amount, merchant, and date) and asks the employee to authorize a single check
Purpose-bound consent. The employee approves a scoped consent: one claim. Nothing broader is granted, and the employee can decline.
Open Banking retrieves the record. Consent is presented to the bank, scoped to that one payment. The licensed Open Banking API accesses the data, encrypts it, and shares it for verification
Compute on encrypted data. Both inputs arrive encrypted. The claim dataset and the bank dataset are each contributed as encrypted shares, and the CCVM runs the match —
f(claim, bank) → match?— without either side being decrypted. Only the result comes out.Verified result. The protocol returns a narrow match verdict: yes or no, and nothing else is disclosed.
Claim decision. The expense platform acts on the verdict: approve matched claims, flag unmatched ones. Verified reimbursements flow through to the employee.
The critical property of this flow is what doesn't move. The claim fields and the bank or payment-provider records are matched cryptographically, each side contributing only encrypted data. The employer confirms the payment happened without ever holding the statement, and the employee keeps their financial privacy intact.
The rails already exist
This isn't a future-state proposal waiting on new infrastructure. Open banking is live, the APIs are standardized, and consent flows are already regulated. What's been missing is the privacy layer that lets an employer verify a transaction without taking custody of sensitive data. Silent Compute is that layer, and it slots onto rails that are already running. Read more about the implementation here: https://md.silencelaboratories.com/s/CQW5fu-fP
The takeaway is simple. Finance teams that keep anchoring trust to uploaded PDFs will keep losing to AI-generated fraud, and the gap will widen as the generators get cheaper and better. Teams that anchor verification to the real transaction source, cryptographically and privately, will build expense workflows that actually hold up.
Sources
SHARE




