OpenClearOpenClear is positive pay software for the bank's side of the service. Business customers send issued checks and set ACH rules. Presented items are matched. Exceptions go to the right people with a deadline, and every decision is recorded in a log that can be verified. It's licensed under the GNU AGPL v3, so a bank, credit union, processor or core provider can run it, read it and change it.
What it covers
| Need | What OpenClear does |
|---|---|
| Check positive pay | Matches presented checks against issued items: not in file, amount mismatch, voided, stop payment, stale-dated, duplicate. |
| Payee positive pay | Reads the payee from the check image with a pluggable OCR engine and fuzzy-matches it against the issue record. |
| ACH positive pay | ACH debit blocks and filters by originator, with optional receiver, amount, frequency and SEC code limits. Exceptions can become standing rules. |
| Reverse positive pay | For customers who don't send an issue file: every presented check is a "to review" item, the customer returns the ones they don't recognize, and the rest pay at the cut-off. A check with a real problem (a stop, a void, a duplicate) follows the customer's default decision instead, so it's never paid by silence. |
| Teller verification | A branch's teller platform asks OpenClear before cashing a business customer's check, and gets "match" or the first problem: not issued, another amount or payee, voided, stopped, stale or already paid. Once cashed, the check is recorded as paid, so the same check presented anywhere later is a duplicate. |
| Issue files | Delimited, Excel and customer-specific fixed-width layouts, built from a sample file. Upload, API or drop folder. |
| Presented items | The core's posted-check file in its own layout (fixed-width or delimited, with the MICR on-us field split into account and check number), X9.37 image cash letters, NACHA ACH files, ZIP of images plus a manifest, or the API. Control totals and trailers are checked, and a file that doesn't balance is refused whole. |
| Exception processing | One queue for checks and ACH, decision deadlines, reminders before the cutoff, default decisions, maker-checker dual control, and returns with reason codes. Decisions can be changed until the cut-off, then lock and reach the bank within a minute. |
| Optional fraud scoring | An advisory fraud-risk score from the bank's own explainable model, trained only on decisions its own people made, with a first model only after 200 of them. It's off until the bank turns it on, it never decides an item, and no data is pooled across banks. |
| Multi-tenant | Many banks in one installation, each with its own business customers, branding and settings. Isolation is enforced in the data layer and tested on every endpoint. |
| Exam readiness | Signed evidence bundles, more than 50 automated control checks, a hash-chained action log, access exports, and documentation mapped to FFIEC, Nacha, check law, GLBA, NYDFS Part 500, SR 11-7, NIST and more. Check deadlines never fall after the midnight deadline. |
| Integration | A JSON API, Python and TypeScript SDKs, SSO (OIDC, SAML) with SCIM, SIEM forwarding, webhooks, decision files for the core, and plugins. |
| Custom fields | The bank's own fields on customers and accounts, such as an account officer code: in forms and lists, the API, data exports, bulk updates and decision files. |
| Offboarding | When a bank or a business customer leaves, its data is deleted after a waiting period, with two-person approval, legal holds, and a signed deletion certificate. Incident and maintenance notices go to each bank's named contacts. |
| Billing | Fee schedules and itemized monthly statements for each customer, plus a posting file for the core. |
| Deployment | SQLite to try it; Postgres or SQL Server in production; Docker; reverse proxy and WAF guidance; more than one instance. |
For community banks and credit unions
Smaller institutions usually get positive pay bundled with their core or online banking platform, priced per account and per item, with little say over how it works. OpenClear offers another route: run it yourself, or have a processor, credit union service organization or technology partner run it for several institutions, which is what the multi-tenant design is for. Each institution keeps its own customers, settings, models and evidence.
Why open source for positive pay
- You can read the rules. The matching rules are short, pure functions in the source. An examiner's "how does the system decide this is an exception?" has an exact answer.
- You can test it before you buy anything. The sandbox and the one-click local install take minutes.
- No lock-in. A full data export for any bank, and the code stays available if the relationship with whoever hosts it ends. When a bank leaves, its data is deleted with a signed certificate. That's a strong exit plan for third-party risk management.
- It shows what's possible. Strong controls like signed audit logs, dual control on configuration and automated control testing are rare in commercial positive pay. They don't have to be.
What it doesn't do yet
The default OCR engine is suited to printed checks, not high-volume handwriting; cloud providers such as AWS Textract and Azure Document Intelligence exist only as stubs so far, behind the same plug-in interface. Each bank publishes its own unauthorized-debit statement form for customers, and obtains and keeps the completed statements its own way. The known gaps are listed in the docs.