Governed authority
Protected actions require the right role, current standing and required qualification at the moment of action.
Check fraud intelligence and check-review operations.
Explainable check fraud intelligence for financial institutions
See exactly why a check was flagged, route it to the right reviewer, govern who may act, and preserve a complete evidence trail — without relying on a black-box fraud score.
Pilots run in a sandbox institution on synthetic checks. No live bank or partner system is certified today, and sandbox results do not prove production behaviour.
- Signal-level evidence
- Every score traces to named signals and recorded evidence.
- Qualified human decision
- The binding decision belongs to the authorized reviewer, not the model.
- Reconstructable proof
- Cases and consequential actions retain the evidence needed to explain what happened.
Check analysisRisk 68 · High
- Routing checksumABA valid · 0 pts
- Amount consistencyNumeric ≠ written · +22
- Duplicate presentmentImage match 0.94 · +18
- Image qualityLegible · unscored
Illustrative example. Every signal carries its own evidence, weight and confidence, and a named reviewer records the binding decision.
How it works
Submit → Analyze → Score → Review → Decide
- 1
Submit
Check data and permitted supporting evidence enter the governed intake flow.
- 2
Analyze
Check-specific deterministic modules inspect the item and record explainable signals.
- 3
Score
Recorded signals produce an explainable 0–100 risk assessment using the current scoring model.
- 4
Review
The reviewer sees what was flagged, why it mattered, the supporting evidence and what still needs human attention.
- 5
Decide
A qualified reviewer records the binding disposition and rationale. Protected actions remain governed and auditable.
What the analyst sees
Anatomy of a flagged check
Every flagged case opens onto the same structure. Nothing in it is generated prose — each line is the evidence the analysis modules actually recorded.
01
Risk score
One 0–100 number, with the risk level and the queue it routed to.
02
Signal decomposition
Each signal that was present, and the weight it contributed to the score.
03
Why each signal mattered
The supporting evidence recorded by the module, in plain language.
04
Which signals counted
Scored signals are listed separately from findings held out of the score.
05
Which signals were experimental
Experimental and never-scored categories are labelled and contribute zero points.
06
Module and version provenance
The module key and version that produced each signal, plus the scoring model version.
07
Human reviewer decision
The named reviewer, the outcome and the rationale — visually separated from the automated recommendation.
08
Immutable audit history
The full event trail, including superseded analysis runs retained rather than overwritten.
From decision to proof
Consequential work stays governed and explainable
CheckGuard does more than record a decision. It governs who may act, tracks what happens outside the system, and preserves the evidence needed to reconstruct consequential work later.
Controlled external actions
Live effects remain bounded by institution settings, approved targets and deployment posture.
Reality verification
A provider acknowledgement is not proof of the final business outcome. CheckGuard records what the external system actually shows.
Owned unresolved work
When an outcome cannot be proven, it becomes visible work with an owner, deadline, escalation and evidence-based resolution.
Control assurance
Material control problems are surfaced deterministically rather than hidden behind a generic health score.
Sealed proof
CheckGuard can assemble a tamper-evident record of a case or consequential action from evidence already recorded, verified inside its trust boundary.
Why institutions can trust it
What is proven, and what is not
Each claim below carries its own status. Nothing is marked verified because it sounds good — only because the product or a regression run demonstrates it today.
01Available now
Explainable scoring
Every point of the 0–100 score traces to a named signal with its evidence, confidence, weight and the module version that produced it.
02Available now
Human decision authority
Analysis recommends. A named reviewer records the binding outcome with rationale, and the recommendation and the decision are shown separately.
03Available now
Check-specific intelligence
Image-derived checks, routing validation, amount, date and payee consistency, duplicate presentment and other deterministic modules contribute explainable evidence. Experimental findings remain visibly unscored.
04Available now
Governed external actions
Protected outward actions are bounded by current authority, institution posture, approved targets and retry-safety rules.
05Available now
Reality reconciliation
A provider acknowledgement is not treated as final proof. CheckGuard separates what was sent from what was subsequently observed.
06Available now
Audit-ready case history
Submission, analysis, assignment, escalation, disposition and re-analysis are all recorded with actor and timestamp, append-only.
07Available now
Control assurance
Current control conditions are evaluated deterministically, with material gaps surfaced as findings rather than hidden behind a generic health score.
08Available now
Sealed proof packages
Supported case and consequential-action records can be assembled into tamper-evident packages and re-verified inside CheckGuard's trust boundary.
What you can put in front of an examinerSee details
- The signals that were present on the item, and the evidence recorded for each.
- The contribution each scored signal made to the 0–100 score.
- The scoring model version and the module version behind every signal.
- The limitations that applied — including capture quality and missing intake information.
- The reviewer actions taken: claim, escalation, information requests.
- The final human decision, its rationale and who recorded it.
- The authority record for protected actions and the history of unresolved work.
- External-action evidence that separates provider acknowledgement from observed outcome.
- Current assurance findings and supported sealed case or action proof packages.
- The complete append-only audit history, including superseded analysis runs.
This is evidence availability inside CheckGuard's trust boundary, not independent attestation or regulatory certification. CheckGuard claims no examiner approval, regulator endorsement, compliance certification or certified live partner integration.
Why institutions choose CheckGuardSee details
- Explainable check-fraud analysis with signal-level evidence.
- Qualified human reviewers retain binding decision authority.
- Operational accountability for unresolved work and consequential actions.
- Controlled external actions with acknowledgement kept separate from outcome proof.
- Evidence lineage from intake and scoring through review and disposition.
- Visible institution readiness, including blockers and work still required.
- Reconstructable audit history and sealed proof inside CheckGuard's trust boundary.
Who it is built for — and what CheckGuard is notSee details
Built for
Check fraud intelligence and check-review operations.
- Financial institutions
- Fraud operations teams
- Fraud analysts and managers
- Fintechs
- Sponsor banks
Not what CheckGuard is
- Not a black-box fraud score or autonomous decision-maker
- Not a generic chatbot or replacement for human authority
- Not proof of an outcome merely because an API acknowledged a request
- Not a self-modifying fraud engine
- Not a claim of live bank integration where none is certified
Integration, capabilities, FAQ & pilot pricingSee details
CheckGuard has API-ready architecture, governed external-source support and sandbox/test integration support. No live bank or partner system is currently certified.
Institution readiness
Tracks what is complete, blocked or still needs action before review, pilot or production capability can become available. Readiness never activates production by itself.
Operational assistant
Explains recorded case facts, readiness blockers, current state and next valid steps without becoming the decision-maker.
Governed improvement
Identifies recurring operational patterns and produces reviewable recommendations without changing production behavior on its own.
Design-partner programme
Run a sandbox pilot on your own check scenarios
Institutions start in a sandbox institution with synthetic captures, then evaluate explanations, routing, evidence, human review and readiness behavior before any production traffic. Sandbox results do not prove production-provider behavior.
See CheckGuard in action — a 4-minute product walkthrough on synthetic data, before you apply.