OpenClearCurrent as of 2026-10-22. Checked against its sources at least once a year (control check regulatory_currency).
How OpenClear supports the areas the FFIEC IT Examination Handbook booklets examine, chiefly Information Security, Architecture, Infrastructure, and Operations, Development, Acquisition, and Maintenance, Audit, Retail Payment Systems and Business Continuity Management. The booklets are principles-based. This page maps OpenClear's controls onto their themes, each with its control id and NIST SP 800-53 Rev. 5 controls; it doesn't cite the booklets' sections. It isn't legal advice (Compliance).
Access control and identity
| Theme | What OpenClear does | Controls (NIST SP 800-53) | Evidence |
|---|---|---|---|
| Least privilege | Per-bank security groups built from fine-grained permissions, checked on every API and web request. Business customers are scoped to their own accounts. | OC-AC-01: AC-3, AC-6 OC-AC-03: AC-3, AC-4, AC-6 OC-AC-04: AC-3, AC-6 |
Settings → Security groups; Users → Export |
| Segregation of duties | Two default rules: whoever submits items can't decide them, and whoever manages users can't define what groups grant. Enforced on groups and per item: the person who presented an item can't decide it. In enforce mode a breach is refused (403 ERR_SOD_VIOLATION); in either mode it's logged. |
OC-AC-05: AC-5 | Settings → Segregation of duties; sod.violation entries in the action log; Controls |
| Dual control | Maker-checker on pay/return decisions, per bank. Settings changes that loosen protection wait for a second person: the protections themselves always; with the bank's switches, sensitive settings (rules, models, groups, API clients, webhooks, sign-on), new or wider access, and a customer's own sign-on and administrators. Nobody approves their own change; a switch can't be turned on without someone else to approve. The service provider's own changes need two of its operators. | OC-AC-06: AC-3(2), AC-5 OC-AC-07: CM-3, CM-5, AC-3(2) OC-AC-13: CM-3, CM-5, AC-3(2), AU-9 |
Settings; Settings → Changes; the evidence bundle's changes |
| Authentication | bcrypt passwords with a per-bank policy; FIDO2/WebAuthn security keys and passkeys; SSO with OIDC or SAML 2.0, group mapping, SCIM provisioning and sign-out from the identity provider. Systems use OAuth 2.0 client credentials, not passwords. | OC-IA-01: IA-5(1), AC-7 OC-IA-02: IA-2(1), IA-2(2), IA-2(8) OC-IA-03: IA-2, IA-8, AC-2(1) OC-IA-04: IA-9, IA-5 OC-IA-05: IA-8 |
Controls → "Admins use a second factor"; Users → Export |
| Vendor and support access | No impersonation: the platform's support staff get into a bank only through access the bank grants, to a named person, for a stated reason and period, read-only unless a second bank admin approves write access, and never to decide items or change who may do what. They work under their own name with a banner; access ends on time or when the bank ends it. Nobody grants their own access. | OC-AC-08: AC-3, MA-4, AC-6(5) | Settings → Support access; support_access.* in the action log and security events; the evidence bundle's support_access |
| Access recertification | Every membership with its group, scope, status and last sign-in, exportable. | OC-AC-02: AC-2, AC-2(3), AC-2(1) | Users → Export (CSV, JSON); GET /api/v1/users |
Data protection
| Theme | What OpenClear does | Controls (NIST SP 800-53) | Evidence |
|---|---|---|---|
| Tenant isolation | On Postgres, row-level security on every bank's tables, bound to the bank on each transaction. | OC-AC-09: AC-4, AC-3 | tests/test_postgres in the source |
| Secrets at rest | Secrets stored in the database (SSO client secrets, the SAML signing key, webhook secrets, secret plugin settings) are AES-256-GCM, versioned by key, and re-encrypted when the key rotates. | OC-SC-01: SC-28(1), SC-12, SC-13 | Controls → "Secrets encrypted in the database" |
| Disk and database encryption | The host's job. The operator records how it's done. | OC-SC-02: SC-28 | Controls → "Disk and database encryption" |
| Integrity of files | Every uploaded file is kept with its SHA-256 and an ECDSA signature. | OC-SC-03: SI-7(6), SC-8 | Bulk upload details |
| Data in transit | HTTPS at the reverse proxy; secure, SameSite cookies; a strict Content-Security-Policy. |
OC-SC-04: SC-23, SC-8, SC-18 OC-SC-05: SC-7 |
README, "Reverse proxy / WAF deployment" |
Logging and monitoring
| Theme | What OpenClear does | Controls (NIST SP 800-53) | Evidence |
|---|---|---|---|
| Audit trail | Every state-changing action, by person or system, with time, channel and details. Each entry is ECDSA-signed and chained to the one before, so an edit, deletion or reordering is detectable. Old entries can move to signed archives without breaking the chain. | OC-AU-01: AU-2, AU-3, AU-9(3), AU-10, AU-12 OC-AU-02: AU-9, SI-7 OC-AU-03: AU-11, AU-9(3) |
Settings → Action log → Verify; Controls → "Action log intact" |
| Log management | Security events (sign-ins and their failures, lockouts, second factors, API tokens, refusals, and changes to who may do what), each with the caller's address, the request and who, and never a secret or account data. Delivered to the bank's SIEM (syslog over TLS as JSON, CEF or LEEF; Splunk HEC; HTTPS) in order and at least once, with retries, from the bank's own destination and the installation's; also readable through a pull API. Events a destination hasn't received are kept until it has. JSON operational logs carry the same request context. | OC-AU-04: AU-12, AU-6(1), SI-4 | Settings → Security event forwarding; Controls → "Security events delivered"; the evidence bundle's security_events; docs/guides/siem.md |
| Continuous monitoring | Live controls with PASS / WARN / FAIL and evidence, by API for a bank's monitoring tools. openclear controls exits non-zero on a failure. |
OC-CA-01: CA-7 OC-CA-02: CA-7, SI-4 |
Settings → Controls |
| Timeliness | Exceptions past or near their decision deadline, stuck imports, a late decision outbox. | OC-SI-05: SI-4, CP-2 OC-SI-06: CA-3 |
Controls → "Decisions and imports on time" |
Development, change and resilience
| Theme | What OpenClear does | Controls (NIST SP 800-53) | Evidence |
|---|---|---|---|
| Secure development | An automated suite of about 1,400 tests on SQLite, Postgres and Linux before each release. A published API contract that changes only additively. A written security review with fixes. | OC-CM-02: CM-3, SI-2, CP-10 | SECURITY_REVIEW.md; CHANGELOG.md; CI |
| Change control in production | Rules and models in force, with a SHA-256 of each, in every evidence export. Two-person approval for settings changes, with the values before and after kept and both people named; a change applied alone after its 24-hour cooling-off is flagged. The provider's own changes in its signed log, and the installation's settings watched until an operator acknowledges them. Database upgrades and downgrades are versioned. | OC-AC-07: CM-3, CM-5, AC-3(2) OC-AC-13: CM-3, CM-5, AC-3(2), AU-9 OC-SI-04: CM-4, CA-2 OC-CM-03: CM-2, CM-8 |
The evidence bundle's rules, models and change_control; Platform → Changes |
| Input handling | A corpus of malformed X9.37 and NACHA files run through the real parsers, which must refuse each cleanly and quickly. | OC-SI-01: SI-10 OC-SI-02: SI-10, SI-7 |
Controls → "Malformed files refused" |
| Production safety | Refuses to start in production with development keys or unsafe options. | OC-CM-01: CM-6 | Controls → "Production settings" |
| Exit | A full export of a bank's data, for migration or offboarding. | — | Settings → Data export |
Retail Payment Systems
The Retail Payment Systems booklet (February 2010, with a 2016 appendix on mobile services) names positive pay as a check-fraud control: the business sends the checks it issued, the bank compares presented checks, and a check not on file goes to the customer for a pay or no-pay decision. Examiners ask whether the bank uses positive pay and whether the issued-check files are protected. OpenClear is on the receiving side only: it decides presented checks and incoming ACH debits. It doesn't originate ACH, so the booklet's ODFI controls (originator limits, return rates) aren't OpenClear's.
| Theme | What OpenClear does | Controls (NIST SP 800-53) | Evidence |
|---|---|---|---|
| Positive pay | Presented checks matched against issued checks; exceptions decided by the customer or the bank before the cut-off, with dual control if the bank turns it on; undecided items take the account's default. | OC-SI-05: SI-4, CP-2 OC-AC-06: AC-3(2), AC-5 |
Exceptions; Controls → "Decisions and imports on time" |
| Issued-check files | A customer's people reach only their own accounts. Each file is kept with its SHA-256 and a signature, parsed by hardened parsers and checked row by row. | OC-AC-03: AC-3, AC-4, AC-6 OC-AC-04: AC-3, AC-6 OC-SC-03: SI-7(6), SC-8 OC-SI-01: SI-10 OC-SI-02: SI-10, SI-7 |
Bulk upload details; Controls → "Malformed files refused" |
| Check fraud at a branch | Teller verification before cash is paid, recorded so a later presentment is a duplicate. | OC-SI-09: SI-4, AC-6 | docs/guides/teller.md |
| ACH debits | A debit from an originator not on the account's authorizations is an exception; customers see the bank's unauthorized-debit statement form. | OC-AC-12: AC-3 OC-SI-07: IR-6 |
Settings → Unauthorized debit statement; Nacha |
| Returns | Each check's midnight deadline is worked out from the day it was presented, and its decision is due before it; decisions lock at the cut-off and go to the core through an outbox with retries. The booklet's return times predate later changes to Regulation CC; Check law has today's. | OC-SI-11: SI-4, SI-10 OC-SI-06: CA-3 |
Controls → "Checks decided within their return deadline" |
| Audit and third parties | A signed evidence export for any period; the third-party pack for due diligence. | OC-AU-05: AU-7, AU-11 | Controls → Export evidence; Third-party risk |
The bank keeps what positive pay doesn't do: account opening and monitoring, kiting detection, and stop payments in the core (B-RA-3-03).
Business Continuity Management
The Business Continuity Management booklet (November 2019) asks a bank to set recovery objectives (RTO, RPO, maximum tolerable downtime) for each critical process, including those a service provider runs, and to check them against what the provider has agreed; to know the provider's resilience and test results; to exercise its plans with critical providers; and to plan for a provider that stops operating.
| Theme | What OpenClear does | Controls (NIST SP 800-53) | Evidence |
|---|---|---|---|
| An outage at the cut-off | Undecided exceptions take the account's default disposition at the deadline. Deadlines are stored, so if OpenClear itself was down, the first sweep after it returns applies them. Decisions wait in the outbox while the core is down. | OC-SI-05: SI-4, CP-2 OC-SI-06: CA-3 |
Customers → Positive pay settings |
| Recovery objectives | The host states its recovery time and point objectives and the date of its last restore test; the Controls page shows them, and warns without them or once the test is over a year old. | OC-CP-01: CP-2, CP-4 | Controls → "Recovery objectives stated" |
| Notice of an outage | The host tells each bank affected, by email and in the app, and records the bank's acknowledgement. | OC-IR-01: IR-6, IR-4 | Platform → Incidents; Incident notification |
| A provider that stops | A full export of a bank's data; OpenClear's source is open (AGPL), so another host or the bank can run it. | — | Settings → Data export |
The bank's part: B-CP-2-01 (plan for an outage at the cut-off), B-CP-2-02 (the teller fallback), B-CP-2-03 (exercise the plan yearly, against the host's objectives). The host's: H-CP-2-01 (state recovery objectives), H-CP-9-01 (back up and test restores).
Sources
Read 22 October 2026: the FFIEC IT Examination Handbook InfoBase, Retail Payment Systems (February 2010; Appendix E, April 2016) and Business Continuity Management (November 2019). In February 2026 the FFIEC removed the Handbook's references to reputation risk and said this sets no new requirements. The InfoBase refuses automated reading, so the booklets' themes here were taken from extracts of their pages, not a full read; their wording is unconfirmed.
Built from docs/compliance/ffiec.md in the OpenClear repository. Last changed October 22, 2026.