A document fraud detection API is the interface through which a claims system sends a document, with enough claim context to judge it, to a testing service, and gets back a verdict and the evidence behind it. For an insurer the call itself is the easy part. What decides its value is where it sits: between the moment an invoice, bill, estimate or receipt arrives and the moment someone pays on it. A check that runs after payment can only start a recovery. Document Fraud Detection is Botminds' solution for testing claim documents before payment. It picks documents up from the portal, email, vendor uploads and bill feeds, reads the claim system and the registers it needs, and writes back one thing: a pass, question or refer verdict with each finding pinned on the page and a note drafted for a person to sign. It never holds a payment or refers a claim by itself.
Where Document Fraud Detection sits: from intake to payment, and who acts
Agent
IntakeTakes each claim document over the threshold from portal, email, vendor upload or bill feed; keeps the original and its SHA-256 fingerprint.
Never: changes the original
Agent
CheckReads fields with positions, tests the file, recomputes the sums, looks up vendor and claim facts, searches past documents.
Agent
NoteApplies the fixed verdict rules and writes back the verdict, findings and a drafted note or referral.
Never: holds a payment or refers by itself
A person decides
AdjusterPass is released; on a question or refer, decides: pay, hold, ask the vendor or refer.
A person decides
PaymentRuns in the claim system as today. Paying against a refer needs a second approval.
What is a document fraud detection API? A document in, evidence out
It is a service call that accepts a claim document and its context and returns a judgement with reasons. The context matters as much as the file. A storage invoice can only be tested against the dates the car was towed and released; a repair invoice against the approved estimate; a medical bill against the dates of service the claim allows. An API that takes only the file can test the file. One that also reads the claim can test whether the document fits the loss it is supposed to support.
The output matters more. A bare score between 0 and 1 tells the adjuster nothing she can check and gives the SIU nothing it can cite. The solution returns findings a person can verify on the page: "stroke 2.3 px, every other figure 1.7 px", "lines add to $4,812.60", "EIN on another business's paid invoice". Every finding carries its test, its level, its measurement and its location, and the verdict follows from fixed rules: any refer-level finding gives refer, question-level findings alone give question, none gives pass.
Where should document checks run in a claim? Before the money moves, as early as possible
Document checks belong at intake, because every regulated claim clock is already running. Florida's personal injury protection statute shows how little room there is. Where an insurer has a reasonable belief of fraud it must notify the claimant in writing within 30 days of the claim; then "the insurer has an additional 60 days to conduct its fraud investigation", and by day 90 it must pay or deny, with interest from the day the claim was submitted (§ 627.736(4)(i)). California allows 40 days to accept or deny a claim, extended to 80 where specific information supports a suspected fraudulent claim (10 CCR § 2695.7).
A Florida PIP fraud clock, and where a check at intake sits on it
- Notice of fraud investigation duedays 1 to 30
- Additional investigation perioddays 31 to 90
- Tested in 41 seconds; every day left for people to investigate90 days
- Waiting for the batch runup to 30 days
- Left to investigate60 days
A test at intake also keeps the insurer out of the position the GAO calls pay-and-chase. Its fraud framework, written for federal programs, prefers automated control activities "because they are less susceptible to human error and are typically more efficient" than manual ones such as document reviews (GAO-15-593SP). The point for an architect is placement: automation that runs on every document before payment, with people deciding on the exceptions.
Can document fraud detection integrate with claims systems? What it reads, what it writes, what stays
Yes, and the cleanest integration is narrow. The service reads from the systems that already hold the facts, writes back a verdict and evidence, and leaves payment, reserves and the claim file of record where they are. In the solution, the read side is six sources and the write side is four items.
The integration map: six sources read, four items written back, four decisions left alone
It reads
It writes back
It never touches
These stay in the claim system and with named people: the adjuster, the SIU and the fraud manager.
The lookups show the integration in action. On the sample Clearwater invoice, the vendor check ran six lookups at 08:12: the carrier's vendor register, the state contractor registration, the tax ID across all claim documents, an address and PO box search, a phone number lookup and the insured and loss address against the claim. Each result came back as a line an adjuster can read.
Six lookups at intake, each one an integration
What does a document fraud API return?
It should return enough for a person to decide and for an investigator to rely on later. That means the verdict, every finding with its measurement and location, the rules version applied, and proof that the document judged is the document received. The last item is easy to overlook and hard to add afterwards. Courts already treat a hash as that proof. The committee note to the 2017 amendment of the Federal Rules of Evidence explains: "If the hash values for the original and copy are the same, it is highly improbable that the original and copy are not identical." (FRE 902).
What Document Fraud Detection returns for each document, and why
| Field | Example from the sample | Who uses it |
|---|---|---|
| Verdict | Refer: 3 refer-level and 3 question-level findings | Adjuster: decides pay, hold, ask or refer |
| Finding | Ink weight, refer: total stroke 2.3 px, every other figure 1.7 px, at the total box | Adjuster puts the lens on it; SIU cites it |
| Finding | Edit history, question: saved again Oct 11 21:47, ten hours before upload | SIU: lays it against the claim timeline |
| Look-alikes | 4 unrelated claims, same template, layout 0.98 to 0.99 | SIU: one case for five claims |
| Draft | Referral with every sentence cited to a pin | Adjuster signs; SIU accepts or declines |
| Fingerprint | SHA-256 of the original as received | Anyone who later needs to show the copy matches |
| Rules version | Version 2.3 of 5 October | Fraud manager and examiners: which rules judged it |
What it should not return is a silent block. In the solution an agent never holds a payment: the verdict asks a person to look, and only the adjuster's hold stops the money. That keeps the insurer's claim-handling obligations with people who can be accountable for them, and it keeps a false finding from doing more than asking a question.
Does document fraud detection slow down payment?
Not for documents that pass, which is most of them. In the sample morning the agents tested 186 claim documents in an average of 38 seconds each; 171 passed and were released for payment without anyone touching them, 12 raised a question and 3 were refer-level. Only those 15 waited for a person, and the person had the findings in front of her rather than a hunch.
A morning's verdicts: most pass in seconds, a few wait for a person
The setting that controls the trade-off belongs to the fraud manager, not the integrator. In the sample, any claim document over $1,000 is tested, medical bills over $500, and every document on a claim already flagged. Lowering a threshold tests more documents and holds none of them by itself; it can only add questions for people to answer.
What file types can document fraud detection read?
The solution reads invoices, medical bills, estimates, receipts and tow and storage tickets as PDF or as photos and scans. The tests that apply depend on the format. A born-digital PDF carries structure: revisions, fonts and text layers that file forensics can read. A photographed receipt carries pixels, compression and camera data, where alignment, stroke weight and re-encoded regions are the evidence. A scan of a printout carries neither history nor much metadata, so the consistency checks do the work. How each kind of trace is read by hand is set out in how to check if a PDF has been altered.
Whatever the format, the document reader places every field with its position on the page, so each finding can be pinned where it is, and low-confidence fields go to a person rather than being guessed. On the sample repair invoice, the reader placed 51 values, and the passed checks are listed beside the two findings: the shop has been on the register since 2019, the arithmetic and tax hold, the VIN matches the policy vehicle, and the file was not edited after export.
A question, not a refer: two findings, four checks passed
Security and data: the API is a third-party provider in your security program
Claim documents carry names, addresses, policy numbers and, on medical bills, health information, so any external service that receives them sits inside the insurer's information security program. The NAIC's Insurance Data Security Model Law says so directly: an insurer must take due care in choosing such a provider, and must require that provider to protect the systems and nonpublic information it holds (Model #668). As of the NAIC's August 2025 brief, 28 jurisdictions had implemented the model (NAIC); states that have not may have their own rules.
Three practical demands follow. Documents should be tested where the insurer's controls apply, not uploaded to a public website. Every incoming file is untrusted input and should be opened in isolation, a point covered in PDF forensics tools. And the service should keep the original unchanged, fingerprinted, and available to the insurer as evidence, rather than holding the only copy.
The detection itself is also something regulators ask about. The NAIC's antifraud plan guideline asks each plan to describe the technology and procedures the insurer uses to spot suspected fraud (GL-1690). Where a state has adopted the NAIC's AI model bulletin, 29 jurisdictions as of 8 October 2026 (NAIC map), fraud detection is one of the uses it names; governance of those systems is covered in AI Governance and Model Inventory. A service that versions its rules and records which version judged each document makes both answers easier to give.
How long does it take to integrate document fraud detection? Start without integrating
The fastest path is to test before you connect anything. A batch of past paid and open documents, exported once, shows what the tests find on your own mix and costs no integration work. Botminds runs Document Fraud Detection on a sample of the carrier's own documents first for exactly that reason. Connecting live intake comes after the carrier has seen what the findings look like and set its thresholds.
An integration order that puts evidence before plumbing
- Batch test on past documents
Export a sample of paid and open documents with claim context. No live connection; findings reviewed by the SIU.
- Read-only registers
Connect the vendor and provider register, price list and registration lookups. They raise the share of findings a person can act on.
- Shadow intake
Test live documents as they arrive, but show the verdicts to a small team only. Measure questions raised and cleared.
- Write-back of verdict and note
Put the verdict and the drafted note into the claim, still with no automated hold.
- Live, with people holding
Adjusters act on questions and refers; the fraud manager owns thresholds and the second approval.
- Past-document search
Index past claim documents for the look-alike search; the bigger the archive, the more templates it can match.
Questions to put to any document fraud detection API
Ask what a person can see and check, what happens to the original, and what the service is allowed to do on its own. The answers separate a service that adds evidence to a claim from one that adds a score nobody can explain.
Eight questions for the vendor's technical team
- Does every finding come with a measurement and a place on the page?
A score alone cannot be checked by the adjuster or cited by the SIU.
- Does it read the claim, or only the file?
Dates, parties, approved amounts and vehicle catch what file tests cannot.
- Can it search our past claim documents?
Template reuse across claims is invisible one document at a time.
- What does it do on its own?
It should never hold a payment, contact a vendor or insured, or refer a claim.
- Is the original kept unchanged, with a hash we hold?
Evidence the insurer cannot produce is not the insurer’s evidence.
- Are the rules versioned and dated?
Examiners will ask which rules applied to which document.
- Where are documents processed, and under whose controls?
Model #668 makes provider due diligence the insurer’s job.
- Can we run it on our own past documents before we connect?
If not, you are buying on someone else’s test set.
Questions people ask
How does a document fraud API work?
The claims system sends a document with its claim context; the service reads the fields, tests the file, recomputes the sums, looks up the vendor and searches past documents, then returns a verdict with its findings. In the sample, the whole run took 41 seconds for one invoice.
Can document fraud detection work in real time?
Yes, for a single document at intake: the sample averaged 38 seconds per document across 186 documents in a morning. Searching a large archive of past documents takes most of that time, and is the step that finds templates reused across claims.
Do we need to replace our claims system?
No. The service reads from the claims system and registers and writes back a verdict, findings and a drafted note; payment, reserves and the claim file of record stay where they are.
What happens when the API is unsure?
Fields read with low confidence go to a person instead of being guessed, and findings from the file alone raise a question rather than a refer. A question asks the adjuster to look; it never holds a payment by itself.
Is a document fraud API a vendor under insurance data-security law?
Usually yes: a service that processes claim documents holds nonpublic information on the insurer's behalf, which the NAIC's model law treats as a third-party service provider requiring due diligence and security requirements. Check your state's version of the law.