CheckCheck
Request a demo

Frequently asked questions

CheckCheck — Frequently Asked Questions

General

What is CheckCheck?

CheckCheck is a digital authentication infrastructure for checks. When a bank issues a check, its key details are sealed into a Digital Watermark — a cryptographic signature of the item. When that check is presented for deposit at any participating institution, CheckCheck authenticates it against that Digital Watermark — confirming the amount, payee, and other critical fields still match what was originally issued.

How does CheckCheck prevent check fraud?

CheckCheck catches fraud by comparing what a check says now against what it said when it was issued. If someone alters the payee name, changes the amount, or creates a counterfeit check, the data won't match the registration record. CheckCheck returns a verification code that tells the depositing bank whether the check is legitimate, suspicious, or definitively altered.

CheckCheck is also uniquely positioned to detect duplicate presentment fraud — where the same check is deposited at multiple banks. Because CheckCheck sees transactions across all participating institutions, it can identify when a check has already been paid elsewhere. No single bank can do this alone.

What is the Digital Watermark?

The Digital Watermark is a cryptographic signature of a check's key details, created when the check is registered at issuance. It serves as a tamper-evident seal: if any critical field on the check is altered afterward, authentication against the Digital Watermark fails. Think of it as a digital fingerprint for each check — and because authentication works from the Digital Watermark alone, CheckCheck can confirm a check is genuine without retaining the underlying account-holder data.

What types of checks does CheckCheck support?

CheckCheck supports all standard check types: personal checks, business checks, cashier's checks, and money orders. It also supports ACH transactions and wire transfers through the same API. Checks can be processed individually via API or in bulk via X9.37 Image Cash Letter files.

Who uses CheckCheck?

CheckCheck is designed for banks and credit unions — both as issuing institutions (registering checks they issue) and as banks of first deposit (verifying checks presented to them). The more institutions that participate, the more effective the network becomes.

Integration

How do we integrate with CheckCheck?

CheckCheck provides a REST API that your existing check processing systems call at two points:

  1. At issuance: When your institution issues a check, your system sends the check data to CheckCheck's registration endpoint.
  2. At presentment: When a check is deposited at your institution, your system sends the check data to CheckCheck's verification endpoint and receives an NCVS code indicating match/mismatch.

Integration typically involves adding API calls to your core banking system or check processing middleware. A Postman collection and step-by-step onboarding guide are provided. You can integrate using either the NCVS verification codes or the simpler boolean fields (signature_valid, hash_match) — whichever fits your systems better.

For a hands-on preview, visit the interactive walkthrough to step through the full check lifecycle — including duplicate presentment detection — with real API calls and live webhook events.

What data formats does CheckCheck support?

How long does integration take?

Most pilot integrations are completed in 1-2 weeks. The API is straightforward — registration is a single POST request, verification is a single POST request. The majority of integration time is spent on your side connecting the API calls to your existing check processing workflow.

How do we safely retry a registration request?

Include an idempotency_key (UUID v4) in the POST /payments/register request body. If a network error causes your system to retry, CheckCheck will return the original payment_id and hash instead of creating a duplicate registration.

{
  "type": "check",
  "idempotency_key": "ba943ff1-ca16-49b2-ba55-1057e70ca5c7",
  "check": { ... }
}

The key is valid for 24 hours per bank tenant. A replayed response includes "idempotent_replay": true to confirm that no new record was created. We strongly recommend generating and storing an idempotency key for every check registration before calling the API.

Are SDKs available?

SDKs are available for Go, Python, and TypeScript, alongside the OpenAPI specification and Postman collection. Banks can also integrate directly with HTTPS/JSON if they prefer not to adopt an SDK.

What does the API response time look like?

Verification responses typically return in under 50 milliseconds. Registration is similarly fast. These times are well within the requirements for real-time check processing at the teller window or during mobile deposit capture.

Verification & NCVS

What is NCVS?

NCVS stands for National Check Verification Service. It's a proposed ABA (American Bankers Association) specification for standardized check verification between financial institutions. The standard is currently under development. CheckCheck has adopted the proposed NCVS response codes as our verification format because they represent the emerging industry consensus for how verification results should be communicated. Using NCVS codes in your integration is optional — CheckCheck also returns simple boolean fields (signature_valid, hash_match) that you can use instead.

What do the verification response codes mean?

Code Name What It Means
M Match All fields match the registration. The check is legitimate.
PM Partial Match Minor discrepancy detected (e.g., payee name abbreviation). Likely legitimate but warrants review.
NM No Match Significant mismatch. The check has likely been altered — possible check washing or tampering.
NR-1 Not Registered The issuing bank is on the network, but this check was never registered. Possible counterfeit.
NR-2 Not Participating The issuing bank is not on the CheckCheck network. Standard risk controls apply.
REJECTED Rejected The check has already been paid or rejected — this is a duplicate presentment attempt.
ERR Error A system error occurred during verification. Retry the request; if the error persists, contact support with the X-Request-Id.
TMO Timeout Verification did not complete within the allowed time window. Retry after a brief delay (1–2 seconds).

What happens if a verification fails?

A failed verification (NM or NR-1 code, or signature_valid: false / hash_match: false) means the check data doesn't match what was registered, or the check was never registered by a participating issuer. Your institution decides how to act on this — CheckCheck provides the data, your risk policies determine the response. Most institutions will reject NM checks and flag NR-1 checks for fraud investigation.

How fast is verification?

Sub-50 millisecond response times are typical. CheckCheck is designed for real-time use during check deposit — whether at the teller window, through mobile deposit capture, or during batch processing.

How do we handle a stop payment order?

Call POST /payments/{id}/void with the payment_id from the original registration. This transitions the payment to voided state immediately and fires a dw.voided webhook event.

curl -X POST https://api.checkcheck.tech/api/v1/payments/chk_abc123def456/void \
  -H "Content-Type: application/json" \
  -H "X-API-Key: chk_your_api_key_here" \
  -d '{
    "voided_by": "ops@yourbank.com",
    "reason": "Customer requested stop payment"
  }'

A voided check will return REJECTED if presented for deposit after the void, protecting your institution and any other participant from accepting a check the issuer has cancelled. Voiding is only allowed before a check has been paid — attempting to void an already-paid check returns 400.

Can CheckCheck detect duplicate deposits?

Yes. Because CheckCheck sees transactions across all participating institutions, it can detect when the same check is presented for deposit at multiple banks. This is one of CheckCheck's core differentiators — duplicate presentment fraud is invisible to any single bank but visible across the network.

When a check that has already been paid is presented again, the verification response returns REJECTED with previously_presented: true and resolution_status: "paid" — giving you an immediate, unambiguous signal to reject the deposit. This works even when the duplicate is presented at a completely different institution.

You can see this in action on the interactive walkthrough, which walks through registering a check, paying it, and then detecting the duplicate.

Security & Compliance

How is our data secured?

What data does CheckCheck store?

You decide, through a configurable storage tier set for your institution. CheckCheck authenticates a check from its Digital Watermark, so it does not need your customers' account data to do its job:

Whatever tier you choose, your data is isolated to your institution and never pooled with another's. Tier changes are governed by your agreement and recorded in the audit trail.

Where is the data hosted?

CheckCheck runs on AWS infrastructure in US regions. All data remains within the United States.

What is the data retention policy?

How much CheckCheck retains is set by your institution's storage tier — by default, no account-holder NPI, just the Digital Watermark and verification results. Whatever is retained is kept for the duration of the pilot period plus a contractual wind-down period, with terms documented in your pilot agreement. CheckCheck does not sell or share individual institution data, and one institution's data is never combined with another's — each institution runs in its own isolated data plane. Any future cross-institution fraud intelligence would be opt-in and governed by explicit data-use rights, anonymization, and lineage controls defined in your agreement.

Does CheckCheck meet regulatory requirements?

CheckCheck is designed to support your institution's compliance obligations. Verification results include full audit trails (request IDs, timestamps, verification codes). CheckCheck's verification codes are aligned with the proposed ABA NCVS standard. All error responses follow RFC 7807 for structured, parseable error handling.

Pilot Program

What's included in the pilot?

The pilot includes:

How do we sign up for the pilot?

Contact the CheckCheck team at info@checkcheck.tech or through your existing relationship. Onboarding involves provisioning your API key, confirming your institution details (routing number, institution type), and scheduling a kickoff call.

What are the system requirements?

Your systems need to be able to make HTTPS REST API calls (JSON over TLS). SDKs are available for convenience, but there is no agent to deploy and no network hardware to configure. If your check processing system can call a REST API, it can integrate with CheckCheck.

Is there a sandbox for testing?

Yes. Pilot participants receive access to a sandbox/demo environment with test data, where you can register and verify test checks without affecting production. Because a pilot runs on infrastructure dedicated to your institution, a successful pilot can be promoted to a production instance quickly — using the same integration, with no re-integration required.

To quickly populate the sandbox with realistic test data, use the POST /sandbox/simulate endpoint. It supports three scenarios:

Scenario What It Creates
duplicate_presentment One check registered and paid, then re-presented — returns the REJECTED / previously_presented: true response live
normal_batch A configurable number (default 10, max 500) of checks with realistic paid/returned/rejected outcomes
fraud_mix A batch including amount spikes and velocity patterns to test your fraud-response integration

This eliminates the need to manually craft dozens of register/resolve calls just to reach an interesting test state.

What support is included during the pilot?

What happens after the pilot?

At the end of the pilot, your institution will have verified data on CheckCheck's effectiveness for your check volume and fraud profile. You'll have integration code that can transition directly to a production agreement. Pricing for ongoing service is discussed during the pilot based on your transaction volume.