Buyer questions, answered plainly

Everything below describes the platform as it is built today. Where something is not done, not certified or not integrated, it says so.

What CheckGuard does today

Frequently asked

Does AI make the final fraud decision?

No. The risk score is produced by deterministic, weighted signals. The AI Investigator is read-only: it summarises and explains evidence already recorded and cannot change a score, create a signal, alter evidence, close a case or declare fraud. Every binding decision is recorded against a named human reviewer with rationale.

What data does CheckGuard store?

Case metadata (amount, date, check number, channel, payee and maker names as submitted), check captures in private storage, machine-generated signals and evidence, reviewer decisions and an immutable audit trail.

Does CheckGuard store full account or routing numbers?

No. Only the last four digits of routing and account numbers are persisted. Full values submitted for validation are used in-request and are not written to the database.

Can CheckGuard integrate by API?

Yes. There is a versioned REST API (v1) for case submission, capture upload, status, and explainable assessments, plus signed outbound webhooks. A machine-readable OpenAPI document is published by the platform.

Is there a sandbox?

Yes. Sandbox is a separate environment bound at the credential level; sandbox cases are flagged and never mix with production records. Production credentials are issued only after a staged activation.

How does tenant isolation work?

Every record carries its institution and every access policy is enforced in the database per record, not in the interface. Cross-institution reads return nothing, including for API credentials, which are bound to one institution and one environment.

Can CheckGuard support multiple reviewers?

Yes. Roles cover submitters, analysts, senior reviewers, institution administrators and platform administrators, with a review queue, senior review lane and escalation path.

Can an institution configure retention?

Retention classes and periods are configurable per institution, with legal hold to suspend deletion and purge batches that record what was removed. Legal-hold and purge authority is restricted.

Is image intelligence explainable?

Yes. Each observation records what was measured, its confidence, the region of the capture it came from, and whether it is calibrated into the score or informational only.

What happens when OCR cannot read a check?

Unreadable or poor-quality captures are treated as an intake problem, not fraud evidence. The case is routed for additional information; image quality never raises the fraud score by itself.

Does CheckGuard compare data across institutions?

No. There is no cross-institution intelligence today. Duplicate and history checks operate strictly inside one institution. Any future network capability would require legal review, participation agreements and privacy architecture first.

Is CheckGuard SOC 2 certified?

No. CheckGuard is not SOC 2 certified and no audit has been performed. We maintain a documented SOC 2 readiness gap map and can share our control descriptions and evidence for diligence.

What core platforms are currently integrated?

None. There are no vendor partnerships or certified core integrations today. Integration is via the CheckGuard API, webhooks, or an adapter built to the institution's transport.

How a design partnership runs

1. Step 1Accepted into design-partner program

   Institution type, use case and pilot appetite confirmed in discovery. · Owner: shared

2. Step 2Institution record created

   Tenant provisioned with its own isolated case, evidence and audit space. · Owner: checkguard

3. Step 3Authorized institution admin identified

   A named administrator who may invite users and assign roles. · Owner: institution

4. Step 4Security and data-handling acknowledgement

   Institution confirms what data may be submitted, and to which environment. · Owner: institution

5. Step 5Sandbox access issued

   Pilot mode enabled; sandbox cases are flagged and never mix with production. · Owner: checkguard

6. Step 6Service account / API key issued (if integrating)

   Least-privilege scopes, sandbox-bound credential, secret shown once. · Owner: shared

7. Step 7Webhook endpoint configured (if integrating)

   HTTPS receiver registered and signature verification tested. · Owner: institution

8. Step 8Synthetic end-to-end test passed

   Case submitted, capture uploaded, analysis returned, webhook received. · Owner: shared

9. Step 9Reviewer training completed

   Reviewers walked through queue, evidence, escalation and disposition. · Owner: shared

10. Step 10Pilot cases loaded

    Approved synthetic or institution-authorized items with expected outcomes. · Owner: institution

11. Step 11Pilot evidence collected

    Labels, reviewer agreement and signal feedback recorded in pilot mode. · Owner: shared

12. Step 12Pilot review meeting held

    Scorecard walked through against the agreed success criteria. · Owner: shared

13. Step 13Go / no-go / extended-pilot decision

    Documented decision with rationale. No decision implies production access. · Owner: shared

14. Step 14Production activation (only if approved)

    Staged activation through the existing integration activation control, audited on completion. · Owner: checkguard

Pricing structure

This is the shape of commercial terms, not a quote. Final pricing depends on volume, institution size and scope.

Integration readiness

CheckGuard has no vendor partnerships and no certified core integrations today. Integration happens through the CheckGuard API, webhooks, or an adapter built to your transport.

Support model (draft)

Draft targets for discussion during onboarding. These are not contractual service levels until they are written into an agreement.